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1.0  Introduction 


One  of  the  major  issues  associated  with  the  use  of  advanced  distributed  simulation  (ADS)  is  the 
credibility  of  the  modeling  and  simulation  (M&S)  used  and  the  credibility  of  their  interactions 
over  a  distributed  network.  The  credibility  of  M&S  is  commonly  measured  by  verification  and 
validation  (V&V)  and  then  formally  approved  as  adequate  for  use  for  a  specific  application  by 
accreditation.  The  V&V  of  M&S  and  distributed  simulations  are  formally  required  by  Department 
of  Defense  (DoD)  Instruction  5000.61,  DoD  Modeling  and  Simulation  (M&S)  Verification, 
Validation  and  Accreditation  (VV&A),  prior  to  their  use  in  testing.  Numerous  guides  and 
pamphlets  exist  which  cover  V&V  requirements,  techniques,  practices  and  tools  (Annex  G). 

Since  Joint  Advanced  Distributed  Simulation  (JADS)  is  a  DoD-sponsored  joint  test,  the  overall 
guide  for  the  V&V  of  the  JADS  End-to-End  (ETE)  Test  will  be  the  Department  of  Defense 
Verification,  Validation  and  Accreditation  Recommended  Practices  Guide.  This  guide  includes  a 
number  of  V&V  processes  that  may  be  used  for  the  V&V  of  M&S  and  ADS  environments  and 
includes  definitions  of  key  terms  used  in  V&V  (Appendix  D).  Specifically,  verification  and 
validation  are  described  as: 

•  Verification-The  process  of  determining  that  a  model  implementation  accurately 
represents  the  developer’s  conceptual  description  and  specifications. 

•  Validation— The  process  of  determining  the  manner  and  degree  to  which  a  model  is  an 
accurate  representation  of  the  real  world  from  the  perspective  of  the  intended  uses  of  the 
model. 

The  JADS  ETE  Test  utilizes  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  Standard 
1278  for  Distributed  Interactive  Simulation  (DIS)  to  develop  its  ADS  synthetic  environment  (SE). 
During  the  development  of  the  IEEE  Standard  1278,  one  of  the  key  methodologies  associated 
with  DIS  was  the  verification,  validation  and  accreditation  (W&A)  process  for  distributed 
simulation  applications.  The  Defense  Modeling  and  Simulation  Organization  (DMSO),  in 
cooperation  with  the  W&A  subgroup  of  the  DMSO/U.S.  Army  Simulation,  Training  and 
Instrumentation  Command  (STRICOM)  Workshop  on  Standards  for  the  Interoperability  of 
Distributed  Simulations,  sponsored  a  project  to  define  the  W&A  process  for  distributed 
simulation  applications  using  DIS.  This  project,  known  as  the  W&A  of  Distributed  Simulations, 
has  developed  a  DIS  W&A  process  model  that  is  an  elaboration  and  expansion  of  the  nine-step 
model  originally  accepted  for  consideration  by  the  10th  DIS  Workshop. 

Within  the  DIS  community,  the  process  model  has  been  extensively  discussed  with  numerous 
members  of  the  DIS  M&S  community  and  has  generally  been  accepted  by  V&V  practitioners. 
The  process  model  has  also  been  selected  by  the  developers  of  the  DoD  W&A  Recommended 
Practices  Guide  as  the  W&A  process  for  DIS  SE.  A  pictorial  of  the  DIS  W&A  process  model 
is  at  Figure  1 . 
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The  process  model  and  its  accompanying  Recommended  Practice  for  Distributed  Interactive 
Simulation  —  Verification,  Validation,  and  Accreditation  (Draft-4  November  1996)  form  the 
basis  for  the  W&A  of  the  ETE  Test  SE. 

The  DIS  Nine  Step  Process  Model  was  developed  with  a  conventional,  short-lived,  DIS  exercise 
in  mind,  as  opposed  to  a  test  of  a  major  system,  and  presupposes  a  full  complement  of  funds  and 
personnel  available  at  the  beginning  of  the  exercise  development.  This  disparity  was  brought  to 
the  attention  of  the  developers  of  the  DIS  Nine  Step  Process  Model,  and  the  conclusion  was 
reached  that  since  the  model  was  recommended  and  intended  for  tailoring  to  the  needs  of  the 
user,  the  model  would  continue  to  be  tied  to  the  DIS  exercise  development  and  construction 
process  contained  within  IEEE  Standard  1278.3. 

If  one  tailors  the  DIS  Nine  Step  Process  Model  to  the  joint  test  process,  then  the  process  model 
would  appear  as  shown  in  Figure  2. 
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Figure  2.  JADS  ETE  Test  Process  Model 


In  the  JADS  ETE  Test  Process  Model,  test  events,  which  consist  of  the  planning,  construction 
and  assembling  of  the  SE,  integration  and  testing  of  the  SE,  accreditation  of  the  SE,  and  conduct 
of  the  test  all  proceed  on  the  left  side  from  top  to  bottom.  The  V&V  events,  to  include 
documentation,  proceed  to  the  right  for  each  test  event. 

The  JADS  ETE  Test  is  presently  executing  the  test  event  shown  as  “Develop  Test  Activity  Plan” 
and  has  started  the  test  event  shown  as  “Construct  and  Assemble  Synthetic  Environment.”  The 
test  events  ‘Conduct  Feasibility  Study’  and  ‘Develop  Program  Test  Plan’  were  completed  three 
and  two  years  ago,  respectively.  As  will  be  shown  later,  formal  V&V  for  these  two  activities  will 
consist  of  documenting  actions  taken  several  years  ago. 

The  major  change  from  the  DIS  W&A  Process  Model  is  the  inclusion  of  the  SE  accreditation  as 
a  part  of  the  test  process,  resulting  in  an  eight  step  V&V  process.  Accreditation  is  not  a  part  of 
the  DIS  exercise  process  in  the  DIS  VV&A  Process  Model.  Instead,  it  is  shown  as  a  part  of  the 
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W&A  process,  and  by  implication  is  not  something  that  is  required  prior  to  the  conduct  of  the 
DIS  exercise.  When  ADS  is  used  in  support  of  operational  and  developmental  testing, 
accreditation  is  a  management  function  and  is  a  mandatory  part  of  the  test  process. 

Finally,  it  should  be  noted  that  the  JADS  ETE  Test  Process  Model  can  be  easily  adapted  to  any 
test  and  does  not  require  the  use  of  DIS  to  develop  the  SE.  Program  test  plan  can  easily  be 
changed  to  test  and  evaluation  master  plan  (TEMP),  and  DIS  could  be  easily  replaced  by  high 
level  architecture  (HLA)  or  aggregate-level  simulation  protocol  (ALSP). 
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2.0  ETE  Test  W&A  Roles  and  Responsibilities 

2.1  JADS  and  ETE  Test  Roles 

The  IEEE  document,  IEEE  1278.3,  Recommended  Practice  for  Distributed  Interactive 
Simulation  —  Exercise  Management  and  Feedback,  describes  the  roles  and  responsibilities  of  the 
personnel,  agencies,  and  systems  involved  throughout  the  exercise  management  and  feedback 
(EMF)  process.  Those  most  closely  associated  with  the  W&A  process  are  identified  below. 

ETE  Test  Manager:  The  person  in  charge  of  planning,  coordinating  and  executing  the  DIS- 
complemented  ETE  Test. 

ETE  Test  Architect:  The  person  responsible  for  designing,  constructing  and  testing  the  DIS- 
complemented  ETE  Test. 

ETE  Test  Sponsor:  The  person  funding  the  DIS-complemented  ETE  Test  development  and 
execution. 

JADS  ETE  Test  Network  Manager:  The  person  or  agency  who  maintains  and  operates  the 
ETE  Test  network  capable  of  providing  the  DIS  link  between  two  or  more  sites. 

2.2  JADS  and  ETE  Test  Responsibilities 

Table  2  identifies  the  individuals,  by  name  and  position  within  the  JADS  Joint  Test  and  Evaluation 
(JT&E)  organization,  who  will  fulfill  the  JADS  and  ETE  Test  roles  identified  in  the  paragraph 
2.1. 

Table  1.  JADS  and  ETE  Test  Responsibilities 


Role 

Name 

Position 

ETE  Test  Sponsor 

Colonel  Mark  Smith 

JADS  Joint  Test  Force  Director 

ETE  Test  Manager 

MAJ  Paul  Hovey 

ETE  Test  Team  Lead 

ETE  Test  Architect 

Mr.  Gary  Marchand 

ETE  Test  Technical  Lead 

JADS  ETE  Test  Network 
Manager 

MAJ  Steve  Sturgeon 

Network  and  Engineering  Team  Lead 
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2.3  V&y  Roles 


Specific  V&V  roles  involved  in  the  V&V  of  the  ETE  Test  are  described  below. 

ETE  Test  V&V  Team  Lead:  The  person  responsible  for  oversight  of  the  ETE  Test  V&V 
activities.  The  ETE  Test  manager  designates  the  V&V  team  lead  who  will  oversee,  coordinate, 
participate  in,  and  integrate  the  V&V  activities  in  support  of  the  test.  The  V&V  team  lead  will 
develop  the  ETE  Test  V&V  plan  and  recommend  the  V&V  participants. 

Accreditation  Agent:  The  person  responsible  for  oversight  of  the  JADS  JT&E  accreditation 
activities.  The  JADS  Joint  Test  Force  (JTF)  director  designates  the  accreditation  agent  who  will 
oversee,  coordinate,  and  integrate  the  accreditation  activities  in  support  of  the  exercise.  The 
accreditation  agent  will  select  personnel  who  will  observe  the  efforts  of  the  ETE  Test  V&V  Team 
and  report  back  to  the  accreditation  agent  as  to  the  validity  and  thoroughness  of  the  V&V  of  the 
ETE  Test  SE. 

ETE  Test  V&V  Team:  The  group  responsible  for  planning  and  conducting  verification  and 
validation  on  the  combination  of  components  that  comprise  the  ETE  Test,  preparing  and 
submitting  the  V&V  report  to  the  accrediting  authority,  and  documenting  the  results  of  the  V&V 
effort. 

Accreditation  Team:  The  personnel  who  will  represent  the  Accreditation  Agent  during  ETE 
Test  V&V  events  and  will  assist  the  accreditation  agent  in  evaluating  the  results  of  the  ETE  Test 
V&V  activities. 

2.4  W&A  Responsibilities 

Table  2  identifies  the  individuals,  by  name  and  position  within  the  JADS  JT&E  organization,  who 
will  fulfill  the  W&A  roles  identified  in  paragraph  2.3. 

Table  2.  W&A  Roles  and  Responsibilities 


Role 

Name 

Position 

Accreditation  Agent 

Mr.  Eric  Keck 

JADS  Technical  Advisor 

ETE  Test  V&V  Team  Lead 

Mr.  Gary  Marchand 

ETE  Test  Technical  Lead 

V&V  Team 

Maj  Mark  Scott 

ETE  Test  Team 

V&V  Team 

Capt  Rod  Houser 

ETE  Test  Team 

Accreditation  Team 

TBD  by  Accreditation  Agent 

TBD 

Accreditation  Team 

TBD  by  Accreditation  Agent 

TBD 
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3.0  ETE  Test  Synthetic  Environment  Requirements  and  Acceptability  Criteria 

Prior  to  conducting  the  V&V  of  a  SE,  one  must  ascertain  the  functional  requirements  and 
acceptability  criteria  from  the  test  plan  and  other  documents  that  describe  the  SE.  The  V&V 
agent  will  then  develop  the  V&V  plan  by  identifying  the  tasks  required  to  meet  these  requirements 
and  acceptability  criteria  in  a  manner  that  matches  and  complements  the  test  activity  plan,  test 
requirements,  component  requirements,  available  resources,  and  timelines. 

3.1  JADS  Program  Test  Plan  --  February  1996 

The  description  of  the  ETE  Test  SE  is  contained  within  the  JADS  Program  Test  Plan  (PTP).  It 
should  be  noted  that  the  SE  employed  in  the  ETE  Test  is  limited  to  a  corps  slice  of  what  would  be 
a  larger  scale  real-world  scenario.  V&V  activities  are  conducted  from  that  perspective.  The  ETE 
Test  SE  is  described  within  the  PTP  as: 

The  test  concept  is  to  use  ADS  to  supplement  the  operational  environment  the  E-8C  and 
ground  station  module  (GSM)  operators  would  experience.  By  mixing  the  available  live 
targets  with  targets  generated  by  a  constructive  model,  a  battle  array  that  approximates 
the  major  systems  present  in  a  “notional  corps”  area  of  interest  can  be  presented. 
Additionally,  by  constructing  a  network  with  nodes  representing  appropriate  command, 
control,  communications,  computers  and  intelligence  (C4I)  and  weapon  systems,  a  more 
robust  cross  section  of  players  is  available  with  which  the  E-8C  and  GSM  operators  can 
interact. 

Several  components  are  required  to  create  the  ADS-enhanced  operational  environment 
that  will  be  used  in  the  ETE  Test.  In  addition  to  Joint  Surveillance  Target  Attack  Radar 
System  (Joint  STARS),  the  ETE  Test  will  require  a  simulation  capable  of  generating 
entities  that  will  represent  the  elements  in  the  rear  of  a  threat  force  (at  least  5000  entities). 
Also,  simulations  of  the  Joint  STARS  moving  target  indicator  (MTI)  radar  and  synthetic 
aperture  radar  (SAR)  will  be  used  to  insert  the  simulated  entities  into  the  radar  processing 
stream  onboard  the  E-8C  while  it  is  flying  a  live  mission.  Other  simulations  used  to 
support  the  test  include  the  Army  Tactical  Missile  System  (ATACMS)  and  a  corps-level 
fire  control  element  (FCE).  Communications  among  these  simulations  will  be 
accomplished  using  doctrinally  correct  means  such  as  All  Source  Analysis  System  (ASAS) 
message  traffic  and  tactical  fire  (TACFIRE)  or  Advanced  Field  Artillery  Tactical  Data 
System  (AFATDS)  message  traffic  encapsulated  within  DIS  communications  protocol 
data  units  (PDU).  Additional  live  elements  that  will  be  integrated  into  the  ETE  Test  SE 
include  the  corps  analysis  and  control  element  (ACE),  which  uses  the  ASAS  and  the  GSM 
or  common  ground  station  (CGS). 
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3.2  Analysis  of  ETE  Test  Concept 


Prior  to  determining  the  requirements  and  acceptability  criteria  for  the  ETE  Test,  it  is  necessary  to 
analyze  the  ETE  Test  concept  in  terms  of  operational  and  ADS  needs  and  characteristics.  These 
needs  and  characteristics  drive  both  the  design  of  the  ETE  Test  SE  and  the  requirements  the  ETE 
Test  SE  must  meet. 

The  ETE  Test  SE  is  actually  composed  of  two  synthetic  subenvironments  (SSE)  which  share  two 
common  components,  the  simulation(s)  that  provides  the  battlefield  environment  and  the  GSM  or 
CGS.  The  first  SSE,  which  will  be  called  the  sensor  SSE,  consists  of  the  simulation(s)  that 
provides  the  battlefield  environment,  the  simulation  of  the  sensor  system  onboard  the  E-8C,  and 
the  GSM  or  CGS.  The  second  SSE,  which  will  be  called  the  command,  control,  communications, 
computers,  intelligence,  surveillance,  and  reconnaissance  (C4ISR)  SSE,  consists  of  the 
simulation(s)  that  provides  the  battlefield  environment;  the  corps  ACE  which  uses  the  ASAS;  a 
simulation  of  the  ATACMS  and  a  corps-level  FCE;  and  the  GSM  or  CGS.  Figure  3  illustrates 
these  two  SSEs  and  their  intersection. 


Figure  3.  ETE  Test  Synthetic  Environment 

The  reason  it  is  important  to  make  these  distinctions  is  that  the  two  SSEs  have  different 
operational  and  ADS  needs  and  characteristics.  The  sensor  SSE  will  deal  with  millions  of  entity 
State  protocol  data  units  (ESPDU)  representing  the  movement  of  thousands  of  entities  across  the 
battlefield.  Operationally,  the  fastest  practical  revisit  time  for  the  sensor  is  on  the  order  of  six 
seconds.  Average  revisit  time  is  approximately  forty  seconds.  In  addition,  the  sensor  is  used  to 
look  at  groups  of  targets,  such  as  a  convoys  or  air  defense  sites,  and  normally  looks  at  a  series  of 
scans,  called  history  files,  taken  over  time. 

The  end  result  is  that  latency  only  becomes  an  issue  when  the  environment  is  broken  or  showing 
very  abnormal  behavior.  Missing  or  damaged  ESPDUs  are  also  not  a  problem  unless  the 
environment  is  broken  or  showing  very  abnormal  behavior,  because  the  probability  of  looking  at  a 
particular  entity  at  any  one  time  is  practically  zero.  A  broken  or  very  abnormal  environment  will 
manifest  itself  in  a  number  of  real-time  ways  long  before  any  post-test  analysis  of  latency  and 
ESPDUs  damaged  or  missing  takes  place. 

The  C4ISR  SSE,  however,  operates  much  differently  then  the  sensor  SSE.  It  consists  primarily  of 
man-in-the-loop  nodes  where  decisions  are  made  and  actions  are  taken  based  upon  information 
received.  It  also  contains  a  weapons  system  with  a  circular  error  probable  (CEP)  that  impacts 
within  the  battlefield  environment  simulation(s).  As  a  result,  the  C4ISR  SSE  uses  two  types  of 
PDUs:  the  message  PDU  (MPDU)  and  the  fire  and  detonate  PDUs.  The  latency  and  dropout  or 
damaged  requirements  for  these  types  of  PDUs  are  very  different. 
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The  MPDU  is  used  to  convey  relatively  nontime  sensitive  information  between  decision  makers 
on  a  non-scheduled  basis  and  thus  is  not  subject  to  normal  latency  considerations.  If  it  takes  more 
than  a  few  seconds  for  the  MPDU  to  travel  from  node  to  node,  the  environment  is  broken.  If  a 
MPDU  is  lost  or  damaged,  however,  that  is  another  matter.  Since  each  MPDU  will  carry 
message  traffic  vital  to  the  SE,  the  loss  of  even  one  PDU  will  have  an  effect  upon  the 
environment. 

The  MPDUs,  however,  carry  standard,  digitized  messages  that  are  normally  transmitted  over 
networks.  One  can  expect  that  some  are  normally  lost  or  damaged  with  a  resultant  effect  upon 
the  operational  environment,  and  this  results  in  what  is  sometimes  called  the  ‘fog  of  war.’  Thus, 
the  true  measure  of  the  degree  of  PDU  dropouts  or  damage  that  the  C4ISR  SSE  can  live  with 
now  becomes  an  evaluation  by  a  subject  matter  expert  (SME)  of  how  ‘foggy’  the  operational 
environment  has  become  as  compared  to  a  live  operational  environment. 

The  fire  and  detonate  PDUs  require  rapid  transmission  across  the  SE  since  they  act  to  notify  the 
SE  of  what  has  happened  in  the  originating  simulation.  The  receiving  simulation  than  uses  the 
information  to  determine  what  effect  the  action  has  upon  itself  and  changes  its  state  to  reflect  this 
effect.  The  simulations  involved  are  closely  coupled,  but  the  fire  PDU  will  serve  primarily  as  an 
alert  because  of  the  long  flight  time  of  the  ATACMS.  Additionally,  the  CEP  is  large  enough  that 
even  if  the  detonate  PDU  is  delayed  by  several  seconds  the  moving  target  location  would  still  fall 
within  the  CEP  of  the  ATACMS.  Since  the  SE  is  not  being  used  to  assess  the  accuracy  nor 
effectiveness  of  the  ATACMS,  and  in  actuality  unclassified  weapons  performance  data  sets  are 
used  to  assess  damage,  any  effect  upon  the  target  is  acceptable.  Once  again,  if  the  SE  is 
functioning  normally,  latency  is  not  an  issue. 

The  detonate  PDU  is  a  critical  PDU  to  the  SE,  and  every  detonate  PDU  must  be  received  by  the 
battlefield  environment  simulation(s).  This  requires  that  each  firing  of  the  ATACMS  must  be 
closely  monitored  by  the  test  control  and  if,  for  whatever  reason,  the  detonate  PDU  is  not 
received,  then  the  mission  must  be  refired.  Based  upon  network  reliability,  it  is  anticipated  that 
this  will  never  occur  during  the  limited  life  of  the  ETE  Test. 

In  conclusion,  it  is  not  possible  to  set  a  priori  values  for  the  SE’s  latency  requirements  and  PDU 
dropout  or  damaged  rates.  Instead,  each  incidence  of  PDU  damage  or  dropout  must  be 
investigated  to  determine  what  effects,  if  any,  the  loss  or  damage  had  on  the  SE.  In  addition,  the 
network  performance  must  be  monitored  to  ensure  that  overall  latency  remains  within  normal 
bounds  as  determined  during  the  network  characterization  phase  of  the  test. 

3.3  Requirements  and  Acceptability  Criteria 

From  this  description  and  analysis  of  the  ETE  Test  SE,  statements  of  work  (SOW)  for  the 
components  of  the  ETE  Test  SE  and  interagency  agreements,  requirements  and  acceptability 
criteria  may  be  derived  for  the  simulations  and  components,  known  as  nodes,  that  comprise  the 
environment  and  for  the  environment  itself.  For  purposes  of  clarity,  the  requirements  and 
acceptability  criteria  will  be  listed  by  node  and  then  for  the  environment  as  a  whole. 
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3.3.1  Simulation  Nodes 


3.3.1.1  J6K 

The  entity  generator  that  will  be  used  in  the  ETE  Test  SE  will  be  based  upon  a  simulation  known 
as  Janus.  It  is  an  Army,  constructive,  entity-level  simulation  under  the  configuration  control  of 
the  Army  Training  and  Doctrine  Command  (TRADOC)  Analysis  Center  (TRAC),  White  Sands 
Missile  Range  (WSMR)  and  STRICOM.  Janus  will  be  modified,  as  appropriate,  to  be  able  to 
represent  at  least  5000  entities.  The  entity-level  data  generated  by  Janus  will  be  converted  into 
ESPDUs  by  an  interface  developed  by  TRAC-WSMR  for  that  purpose. 

Requirements 

•  Capable  of  simulating  or  of  being  modified  to  simulate  at  least  5000  distinct  entities  with  at 
least  twenty-five  percent  moving,  in  a  reasonable  and  affordable  manner. 

•  Capable  of  issuing  DIS  2.0.4  ESPDUs  that  describe  each  entity  simulated. 

•  Capable  of  receiving  and  acting  upon  ESPDUs,  fire  PDUs,  and  detonation  PDUs. 

•  Capable  of  running  for  at  least  eight  hours  with  human  intervention  as  required. 

•  Capable  of  running  at  or  representing  real-time  actions. 

•  Must  use  terrain  data  base  at  least  200  kilometers  (km)  by  200  km  and  based  on  National 
Imagery  and  Mapping  Agency  products. 

•  Must  have  a  V&V  history,  an  accreditation  history  for  analysis,  be  under  configuration 
control,  and  be  well  documented. 

•  Must  reasonably  represent  entity  movement,  stopping,  and  turning. 

•  Must  represent  the  effects  of  a  bombing  or  missile  attack  on  the  entities  represented  in  an 
acceptable  and  credible  manner. 

Acceptability  Criteria 

•  At  least  5000  entities  with  at  least  twenty-five  percent  moving  will  be  simulated  using  a 
commercial  off-the-shelf  (COTS)  product  costing  less  then  100,000  dollars. 

•  Each  ESPDU  will  conform  with  the  DIS  2.0.4  standards  as  amended  by  JADS  as  to  content 
and  format. 

•  The  simulation  will  receive  and  act  upon  each  ESPDU,  fire  PDU,  and  detonate  PDU  issued  to 
it  by  the  network  and  will  take  the  appropriate  action  as  dictated  by  the  PDU  provided  the 

•  appropriate  data  sets  regarding  the  PDU  have  been  entered  into  the  simulation. 

•  The  simulation  will  accept  and  process  scenarios  with  a  duration  longer  than  eight  hours. 

•  The  operators)  will  be  capable  of  fully  interacting  with  a  scenario  while  it  is  running. 

•  The  simulation  will  be  capable,  when  running,  of  proceeding  in  a  step-wise  fashion  at  a  pace 
representative  of  real  time.  That  is,  when  a  unit  of  game  time  is  represented  within  Janus  a 
corresponding  amount  of  time  will  have  elapsed  since  the  start  of  the  simulation.  This  feature 
will  be  adjusted  by  tuning  the  scenario. 

•  The  simulation  will  be  capable  of  utilizing  scenarios  conducted  upon  terrain  representing  a 
simulation  area  of  200  km  by  200  km. 
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•  The  simulation  will  have  a  V&V  history,  an  accreditation  history  for  analysis,  be  under 
configuration  control,  and  be  well  documented. 

•  The  simulation  will  represent  vehicle  behavior  to  the  degree  detectable  by  a  Joint  STARS 
target  analyst  using  an  Advanced  Technology  Work  Station  (ATWS). 

•  Area  coverage  and  attrition  for  area  weapons  will  be  representative  of  the  real  weapon 
system.  Unclassified  data  sets  will  be  used  for  the  ETE  Test  as  the  JADS  ETE  Test  is  not 
testing  area  weapon  effects.  The  simulation  must  be  capable  of  using  classified  data  sets  to 
represent  actual  weapons  effects  if  so  required. 

3.3. 1.2  Target  Acquisition  Fire  Support  Model  (TAFSM). 

The  simulation  that  will  be  located  at  Fort  Sill,  Oklahoma,  and  represents  the  ATACMS  and  a 
corps-level  FCE  is  known  as  TAFSM.  It  is  a  constructive  model  that  is  under  the  configuration 
control  of  the  Depth  and  Simultaneous  Attack  Battle  Lab  (DSABL).  The  simulation  is  used 
extensively  in  analysis  of  alternatives  (AOA),  doctrinal  studies,  and  training  by  numerous 
agencies. 

Requirements 

•  Simulation  must  be  a  doctrinally  correct  simulation  of  a  corps-level  artillery  battle  that  is 
verified,  validated  and  accredited  for  training  and  analysis  by  the  DSABL. 

•  Simulation  must  be  capable  of  receiving  artillery  missions  via  DIS  PDUs  and  broadcasting  fire 
and  detonation  PDUs  when  artillery  weapons  are  fired. 

•  Simulation  must  represent  all  fielded  artillery  systems  to  include  the  ATACMS. 

Acceptability  Criteria 

•  Simulation  must  be  accredited  for  training  and  analysis  by  DSABL  for  use  in  representing  in  a 
doctrinally  correct  manner  a  corps-level  employment  of  ATACMS 

•  Simulation  will  accept  artillery  missions  using  TACFIRE  or  AFATDS  messages  encapsulated 
in  a  DIS  PDU.  Simulation  will  issue  a  fire  and  detonate  PDU  whenever  an  ATACMS  missile 
is  fired  and  subsequently  detonated. 

•  Simulation  will  represent  the  performance  characteristics  of  the  ATACMS  in  a  matter 
acceptable  to  the  DSABL. 

3.3. 1.3  Virtual  Surveillance  Target  Attack  Radar  System  (VSTARS). 

The  simulation  of  the  radar  onboard  the  E-8C  subsystem  is  called  the  Virtual  Surveillance  Target 
Attack  Radar  System  (VSTARS).  It  is  being  developed  by  Northrop  Grumman  and  Lockheed 
Martin  and  integrated  into  the  radar  subsystem  by  Northrop  Grumman.  VSTARS  is  composed  of 
an  integration  and  management  set  of  software  and  simulations  of  the  two  radar  modes  onboard 
the  aircraft:  SAR  and  MTI  radar.  When  used  within  the  laboratory,  VSTARS  will  also  use 
existing  navigation  and  programmable  signal  processor  (PSP)  simulations.  Requirements  and 
acceptability  criteria  for  VSTARS  overall  and  the  components  of  VSTARS  will  be  addressed 
separately. 
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Requirements 

•  VSTARS  will  enable  the  mixing  of  MTI  radar  virtual  entities,  terrain,  and  SAR  images  in  a 
seamless  manner  with  the  actual  radar  images  produced  by  the  E-8C  while  performing  an 
operational  mission.  VSTARS  will  operate  within  the  timeline  standards,  utilize  the  same 
system  parameters,  and  use  the  same  message  formats  established  for  the  Joint  STARS  radar 
system. 

•  When  installed  on  the  E-8C,  VSTARS  will  provide  simulated  radar  data  integrated  with  live 
radar  data  when  operating  within  the  JADS  JTF  ETE  Test  environment. 

•  For  MTI  radar  reports,  VSTARS  will  allow  operation  in  three  modes:  live,  where  all  data  are 
provided  by  the  radar  operating  system;  mixed,  where  both  live  and  virtual  data  are  provided; 
and  virtual,  where  all  data  are  provided  by  VSTARS.  SAR  reports  will  be  either  real  or 
virtual  with  no  mixing. 

•  In  all  modes  of  operation,  VSTARS  will  permit  all  of  the  normal  operations  performed  by  the 
console  operator  to  remain  possible,  such  as  target  tracking,  target  type  identification,  etc., 
even  though  most  or  all  of  the  targets  are  virtual  entities. 

•  When  working  on  a  VSTARS  supplemented  workstation,  the  operators  should  not  be  able  to 
easily  distinguish  between  live  and  virtual  targets,  either  visually  or  as  a  result  of  any  action 
normally  taken  in  the  course  of  performing  their  duties. 


12 


Acceptability  Criteria 

•  VSTARS  will  be  integrated  into  the  Joint  STARS  radar  subsystem  in  such  a  manner  as  to  be 
transparent  to  the  operations  and  control  (O&C)  subsystem,  thereby  permitting  the  mixing  of 
virtual  entities,  terrain,  and  SAR  images  in  a  seamless  manner  with  the  actual  radar  images 
produced  by  the  E-8C  while  performing  an  operational  mission. 

•  VSTARS  must  receive  virtual  target  data  from  the  JADS  JTF  ETE  Test  environment  and 
integrate  it  with  live  target  data  received  and  processed  by  the  radar  subsystem. 

•  For  MTI  reports  VSTARS  operates  in  three  modes:  only  live  targets  displayed,  mixed  live 
and  virtual  targets  displayed,  and  only  virtual  targets  displayed.  Display  will  be  upon  the 
currently  installed  version  of  the  operator's  workstation.  VSTARS  will  permit  the  SAR  report 
to  consist  of  either  a  real  report  or  a  virtual  report. 

•  In  all  modes  of  operation,  VSTARS  will  permit  all  of  the  installed  operator  workstation 
software  to  function  without  abnormal  fault  messages  occurring.  Abnormal  fault  messages 
are  defined  as  those  caused  specifically  by  the  use  of  VSTARS. 

•  VSTARS  will  present  all  virtual  radar  results  using  the  standard  format  for  MTI  and  SAR 
reports.  For  the  MTI  reports,  virtual  targets  will  exhibit  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar.  Operational  behavior 
characteristics  of  the  virtual  targets  will  not  differ  noticeably  from  the  operational 
characteristics  of  real  targets  Virtual  SAR  reports  will  also  exhibit  radar  performance 
measures  as  defined  during  developmental  testing  of  the  Joint  STARS  radar.  In  addition, 
virtual  SAR  reports  will  exhibit  an  acceptable  degree  of  fidelity  matching  that  found  in  actual 
images. 

3.3. 1.4  Ground  Network  Interface  Unit  (GNIU) 

Requirements 

•  The  ground  network  interface  unit  (GNIU)  will  receive  and  process  DIS  2.0.4  ESPDUs  at  a 
rate  equal  to  or  greater  than  350  ESPDUs  per  second. 

•  The  GNIU  will  perform  a  coordinate  transform  upon  entities  selected  for  transmittal  to  the  air 
network  interface  unit  (ANIU)  and  prepare  a  VSTARS  data  packet  containing  all  entity  data 
required  by  the  radar  processor  simulator  and  integrator  (RPSI)  for  transmission  to  the  ANIU. 

•  The  VSTARS  data  packet  will  be  less  then  527  bits.  Total  bandwidth  requirements  for  the 
link  between  the  GNIU  and  ANIU  will  be  less  than  19.2  kilobits  per  second  (Kbits/sec). 

•  The  GNIU  will  prepare  and  transmit  an  ESPDU  reflecting  the  entity  state  of  the  E-8C  based 
on  data  received  from  the  ANIU. 

Acceptability  Criteria 

•  The  GNIU  receives  and  processes  DIS  2.0.4  ESPDUs  at  a  rate  greater  than  350  ESPDUs  per 
second. 

•  Filtering  schema,  such  as  the  GNIU  determining  if  arriving  ESPDUs  are  within  VSTARS  area 
of  interest,  are  employed 
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•  The  GNIU  performs  a  coordinate  transform  upon  entities  selected  for  transmittal  to  the  ANIU 
and  prepares  a  VSTARS  data  packet  containing  all  entity  data  required  by  the  RPSI  for 
transmission  to  the  ANIU. 

•  The  VSTARS  data  packet  is  less  then  527  bits.  Total  bandwidth  requirements  for  the  link 
between  the  GNIU  and  ANIU  are  less  than  19.2  Kbits/sec. 

•  The  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity  state  of  the  E-8C  based  on 
data  received  from  the  ANIU. 

3. 3. 1.5  Air  Network  Interface  Unit  (ANIU) 

Requirements 

•  Operate  upon  and  be  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  Receive  and  process  VSTARS  data  packets  at  a  rate  commensurate  with  a  maximum 
bandwidth  of  19.2  Kbits/sec. 

•  Store  entity  data  received  in  an  ANIU  target  database. 

•  Conduct  dead  reckoning  upon  moving  targets  at  a  minimum  rate  of  1  hertz  (Hz)  and  store 
revised  locations  in  the  ANIU  target  database. 

•  Provide,  from  the  navigational  update  message  available  from  the  navigation  subsystem,  the 
necessary  data  required  for  the  GNIU  to  construct  an  ESPDU. 

Acceptability  Criteria 

•  Operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  Receives  and  processes  VSTARS  data  packets  at  a  rate  commensurate  with  a  maximum 
bandwidth  of  19.2  Kbits/sec. 

•  Stores  entity  data  received  in  an  ANIU  target  database. 

•  Conducts  dead  reckoning  upon  moving  targets  at  a  minimum  rate  of  1  Hz  and  stores  revised 
locations  in  the  ANIU  target  database. 

•  Provides,  from  the  navigational  update  message  available  from  the  navigation  subsystem,  the 
necessary  data  required  for  the  GNIU  to  construct  an  ESPDU. 

3.3. 1.6  Radar  Processor  Simulator  and  Integrator  (RPSI)  Management  and  Integration 

Software  (M&IS) 

Requirements 

•  Operate  upon  and  be  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  Receive  the  details  of  a  radar  mission  from  the  radar  subsystem  as  a  PSP  parameter  message 
and  determine  if  it  is  an  MTI  or  SAR  mission.  Determine  from  the  PSP  parameter  message 
the  coordinates  of  the  area  covered  by  the  mission  and  retrieve  from  the  ANIU  target  database 
all  targets  that  are  located  within  the  area.  Append  the  targets  to  the  PSP  parameter  message 
and  send  to  the  appropriate  simulation  depending  upon  mission  type. 

•  For  MTI  radar  missions,  receive  the  outputs  from  the  radar  processor  and  the  MTI  simulation 
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and  determine  the  appropriate  distribution  of  targets  within  the  area  covered  by  the  mission 
based  on  mode  of  operation  (real,  virtual,  or  mixed).  Send  the  composite  target  report  to  the 
radar  post-processor. 

•  For  SAR  missions,  receive  the  outputs  from  the  radar  processor  and  Advanced  Radar  Imaging 
Emulation  System  (ARIES)  and  determine  if  the  mission  is  for  a  real  area  or  a  virtual  area. 
Forward  the  appropriate  report,  real  or  virtual,  to  the  radar  post-processor. 

Acceptability  Criteria 

•  Operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  Receives  the  details  of  a  radar  mission  from  the  radar  subsystem  as  a  PSP  parameter  message 
and  determines  if  it  is  an  MTI  or  SAR  mission.  Determines  from  the  PSP  parameter  message 
the  coordinates  of  the  area  covered  by  the  mission,  and  retrieves  from  the  ANIU  target 
database  all  targets  that  are  located  within  the  area.  Appends  the  targets  to  the  PSP 
parameter  message  and  sends  them  to  the  appropriate  simulation  depending  upon  mission 
type. 

•  For  MTI  radar  missions,  receives  the  outputs  from  the  radar  processor  and  the  MTI 
simulation  and  determines  the  appropriate  distribution  of  targets  within  the  area  covered  by 
the  mission,  based  on  mode  of  operation  (real,  virtual,  or  mixed).  Sends  the  composite  target 
report  to  the  radar  post-processor. 

•  For  SAR  missions,  receives  the  outputs  from  the  radar  processor  and  ARIES  and  determines 
if  the  mission  is  for  a  real  area  or  a  virtual  area.  Forwards  the  appropriate  report,  real  or 
virtual,  to  the  radar  post-processor. 

3.3.1. 7  Moving  Target  Indicator  (MTI)  Radar  Simulation 

Requirements 

•  Operate  upon  and  be  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  The  MTI  simulation  will  receive  PSP  parameter  messages  from  the  RPSI  M&IS  and  perform 
the  necessary  functions  to  simulate  the  Joint  STARS  MTI  signal  processing.  The  emulation 
will  represent  radar  performance  measures  as  defined  during  developmental  testing  of  the 
Joint  STARS  radar  and  will  consider  environmental  effects  that  affect  the  radar’s 
performance. 

•  The  simulation  will  be  performed  on  a  dwell  basis. 

•  The  simulation  will  have  no  perceived  impact  upon  the  radar  timeline. 

Acceptability  Criteria 

•  Operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  The  MTI  simulation  receives  PSP  parameter  messages  from  the  RPSI  M&IS  and  performs  the 
necessary  functions  to  simulate  the  Joint  STARS  MTI  signal  processing.  The  emulation 
represents  radar  performance  measures  as  defined  during  developmental  testing  of  the  Joint 
STARS  radar  and  considers  environmental  effects  that  affect  the  radar’s  performance. 

•  The  simulation  performs  on  a  dwell  basis. 
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•  The  simulation  has  no  perceived  impact  upon  the  radar  timeline. 

3.3.1.8  Advanced  Radar  Imaging  Emulation  System  (ARIES) 

Requirements 

•  Operate  upon  and  be  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  ARIES  will  receive  PSP  parameter  messages  from  the  RPSI  M&IS  and  perform  the  functions 
required  to  generate  a  proper  Joint  STARS  SAR  image.  ARIES  will  represent  radar 
performance  measures  as  defined  during  developmental  testing  of  the  Joint  STARS  radar  and 
will  consider  environmental  effects  that  affect  the  radar’s  performance 

•  ARIES  will  format  the  image  information  into  the  proper  Joint  STARS  format  for  transmittal 
to  the  RPSI  M&IS  and  subsequent  transmittal  to  the  radar  post-processor. 

•  ARIES  will  visually  match  the  fidelity  of  Joint  STARS  SAR  images  as  determined  by  the 
naked  eye. 

•  The  simulation  will  have  minimal  impact  upon  the  radar  timeline  such  that  the  issue  of  real 
versus  simulated  image  will  not  be  decided  based  upon  timing  alone. 

Acceptability  Criteria 

•  Operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and  hardware. 

•  ARIES  receives  a  PSP  parameter  message  from  the  RPSI  M&IS  and  performs  the  functions 
required  to  generate  a  proper  Joint  STARS  SAR  image.  ARIES  represents  radar  performance 
measures  as  defined  during  developmental  testing  of  the  Joint  STARS  radar. 

•  ARIES  formats  the  image  information  into  the  proper  Joint  STARS  format  for  transmittal  to 
the  RPSI  M&IS  and  subsequent  transmittal  to  the  radar  post-processor. 

•  ARIES  visually  matches  the  fidelity  of  Joint  STARS  SAR  images  as  determined  by  the  naked 
eye. 

•  The  simulation  has  minimal  impact  upon  the  radar  timeline  such  that  the  issue  of  real  versus 
simulated  image  will  not  be  decided  based  upon  timing  alone. 

3.3.1.9  Programmable  Single  Processor  (PSP)  Simulation  (Laboratory  Only) 

Requirements 

•  Must  receive  and  process  radar  service  requests  from  O&C  subsystem 

•  Must  request  and  receive  navigation  information  from  the  navigation  simulation 

•  Must  develop  and  issue  to  RPSI  M&IS,  a  PSP  parameter  message  corresponding  to  a  specific 
radar  service  request. 

Acceptability  Criteria 

•  Receives  and  processes  radar  service  requests  from  O&C  subsystem 

•  Requests  and  receives  navigation  information  from  the  navigation  simulation 
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•  Develops  and  issues  to  RPSI  M&IS,  a  PSP  parameter  message  corresponding  to  a  specific 
radar  service  request. 

3.3.1.10  Navigation  Simulation  (Laboratory  Only) 

Requirements 

•  Must  simulate  the  position,  altitude  and  speed  of  an  E-8C  aircraft  flying  a  specified  orbit  and 
provide  these  data  to  the  navigation  software  associated  with  the  radar  function. 

•  Must  provide  the  required  data,  reports  and  messages  to  the  radar  subsystem  as  called  for  by 
the  PSP  simulation. 

Acceptability  Criteria 

•  Simulates  the  position,  altitude  and  speed  of  an  E-8C  aircraft  flying  a  specified  orbit  and 
provides  these  data  to  the  navigation  software  associated  with  the  radar  function. 

•  Provides  the  required  data,  reports  and  messages  to  the  radar  subsystem  as  called  for  by  the 
PSP  simulation. 

3.3.2  ETE  Test  Synthetic  Environment  (ETE  Test  SE) 

Requirements 

•  Using  DIS  PDUs,  provide  doctrinally  correct  C4ISR  connectivity  required  to  conduct  the 
end-to-end  sequence.  This  sequence  is  defined  as  target  detection,  target  selection,  target 
engagement,  and  battle  damage  assessment. 

•  Using  DIS  PDUs,  provide  near  real-time  virtual  situational  awareness  to  the  Er8C  aircraft  in 
the  laboratory  and  onboard  the  aircraft  during  an  operational  mission.  The  timeliness  of  the 
situational  data  presented  to  the  operators  onboard  the  aircraft  is  determined  by  a  number  of 
factors:  radar  mode  used  for  a  specific  situation,  weather,  and  range  to  target.  At  a 
minimum,  data  presented  to  the  operators  are  5  to  6  seconds  old  and  can  be  a  minute  or  more 
old. 

•  Latency  requirements  for  the  ETE  Test  SE  PDUs  are  coupled  to  many  factors:  the 
requirement  for  near  real-time  virtual  situational  awareness  and  the  CEP  associated  with  each 
individual  virtual  target.  Based  on  the  CEP  alone,  it  is  anticipated  that  the  minimally 
acceptable  latency  for  ESPDUs  will  be  on  the  order  of  several  seconds.  This  requirement 
cannot  be  stated  as  a  specific  value  but  instead  is  stated  as  the  latency  associated  with  each 
PDU  shall  be  small  enough  so  as  to  not  invalidate  the  data  derived  from  the  PDU. 

•  The  requirement  for  determining  a  corrupted  or  lost  PDU  rate  is  also  difficult  to  quantify. 
There  are  three  distinct  categories  of  PDUs  in  the  ETE  Test  SE  with  vastly  different  reliability 
requirements.  Those  that  update  the  situation  or  sensor  must  be  reliable  to  the  extent  that  the 
overall  situation  presented  by  the  sensor  is  not  appreciably  different  from  the  situation  present 
in  the  scenario  driver.  As  an  example,  if  one  vehicle  out  of  a  convoy  of  100  vehicles  is 
missing  because  of  a  lost  or  corrupted  PDU,  there  is  little  or  no  change  in  the  situation 
presented  by  the  sensor.  However,  if  the  only  missile  transportor,  erector,  launcher  (TEL)  is 
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missing  from  a  convoy  of  three  vehicles  because  of  a  lost  or  corrupted  PDU,  there  is  a  drastic 
change  in  the  situation  presented  by  the  sensor.  The  same  is  true  of  PDUs  that  carry  critical 
commands  and  PDUs,  such  as  the  detonate  PDU,  that  initiate  a  critical  reaction  in  the 
simulation  receiving  the  PDU.  In  other  words,  valid  PDUs  must  be  received  reliably  enough 
that  the  event  or  situation  they  are  a  part  of  is  correctly  represented.  If  incorrectly  represented 
situations  or  events  do  occur,  they  must  have  a  disrupting  influence  on  the  overall  SE  for  them 
to  be  counted  against  the  requirement.  In  addition,  these  incorrect  situations  must  occur  at  a 
rate  noticeably  different  from  the  events  in  real  life  for  targets  are  often  not  detected  because 
of  low  probability  of  detection,  and  messages  are  often  lost  or  garbled  because  of  atmospheric 
effects  or  jamming. 

Acceptability  Criteria 

•  The  end-to-end  sequence  is  conducted  in  a  doctrinally  correct  manner  using  the  ETE  Test  SE. 

•  Near  real-time,  virtual  situational  awareness  is  provided  to  the  sensor  system  represented  by 
VSTARS. 

•  The  latency  associated  with  each  PDU  will  be  small  enough  that  the  data  provided  by  the 
PDU  remain  valid  for  the  simulation  receiving  the  PDU. 

•  The  rate  of  PDUs  lost  or  corrupted  will  be  low  enough  for  each  type  of  PDU  that  the  ETE 
Test  SE  will  be  perceived  as  representing  reality. 


18 


4.0  ETE  Test  V&V  Status  and  Requirements 


Prior  to  describing  the  verification  and  validation  events  that  will  be  carried  out  as  a  part  of  this 
plan,  it  is  necessary  to  describe  the  current  V&V  status  of  each  node  in  the  ETE  Test  SE.  This 
status,  when  compared  with  the  requirements  and  acceptability  criteria  for  each  node,  will 
identify  the  additional  V&V  activities  that  must  be  performed  for  each  node.  This  is  an  important 
step  in  developing  a  V&V  plan,  since  the  identification  of  requirements  that  have  been  met  by 
prior  V&V  efforts  will  save  valuable  resources  and  permit  more  time  and  effort  to  be  placed  on 
those  requirements  that  are  unique  to  the  ETE  Test  SE. 

It  should  also  be  noted  that  the  ETE  Test  SE  contains  nodes  that  are  composed  of  live  elements 
and  fielded  equipment.  Technically  speaking,  one  does  not  V&V  a  live  node.  By  definition,  the 
node  is  valid,  and  it  performs  like  the  real  piece  of  equipment  because  it  is  the  real  piece  of 
equipment.  What  one  must  do,  however,  is  determine  that  the  live  elements  are  trained  to 
function  in  a  doctrinally  correct  manner  and  in  the  proper  use  of  the  equipment.  In  addition  one 
must  test  that  the  interfaces  to  the  SE  function  properly.  These  tasks  will  be  performed  as  a  part 
of  the  V&V  of  the  ETE  Test  SE  and  will  be  so  indicated  below. 

4.1  V&V  Status 

The  following  briefly  reviews  the  V&V  status  of  the  legacy  models  contained  in  the  ETE  Test  SE. 
A  part  of  the  V&V  of  the  ETE  Test  is  to  review  the  requirements  for  each  simulation,  and 
conduct  or  have  conducted  V&V  activities  to  satisfy  those  requirements  not  already  satisfied  by 
previous  V&V  efforts.  The  V&V  status  reported  herein  will  focus  on  the  requirements  met,  while 
the  following  sections  will  focus  on  additional  V&V  activities  to  be  performed. 

4.1.1  J6K 

The  simulation  known  as  J6K  is  based  upon  Janus,  Version  6,  which  is  under  the  configuration 
control  of  STRICOM  and  TRAC-WSMR.  The  name  stands  for  Janus,  Version  6,  with  thousands 
of  entities.  Currently,  J6K  is  capable  of  representing  up  to  9999  entities.  Janus  is  an  interactive, 
two-sided,  closed,  stochastic,  ground  combat  simulation  featuring  precise  color  graphics.  Janus 
has  been  accredited  for  use  in  combat  development  studies  such  as  cost  and  operational 
effectiveness  analyses  (COEA)  or  AOAs,  operational  test  planning  and  post-test  studies,  and 
training.  Janus  accurately  models  weapons  systems  as  a  function  of  each  system’s  capabilities  as 
affected  by  terrain  and  weather.  The  Janus  data  bases  describe  systems  extensively  and  in  detail. 
Individual  fighting  systems  have  distinct  properties:  dimensions,  weight,  carrying  capacity,  speed, 
weapons,  and  weapons  capabilities  like  range,  type  of  ordnance,  and  ammunition  basic  load. 
Multiple  sets  of  data  bases  may  be  available  for  different  uses,  day  and  night,  for  instance,  or 
classified  and  unclassified. 

Janus  is  composed  of  multiple  software  modules,  such  as  the  terrain  editor  (TED)  and  the 
command  and  control  overlay  editor,  which  are  required  to  develop  scenarios  and  databases  used 
during  the  running  of  Janus.  Changes  made  to  J6K  for  these  modules  involve  changing  sizes  of 
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arrays,  databases,  and  files.  These  changes  do  not  affect  the  validity  of  Janus  except  that  as  the 
sizes  of  the  arrays,  databases,  and  files  increase,  Janus  may  have  difficulty  in  running  in  near  real 
time.  For  this  reason,  each  scenario  developed  for  Janus  must  be  tuned  by  adjusting  the  level  of 
activity  within  the  scenario  such  that  near  real-time  operation  is  achieved. 

The  software  module  that  depicts  the  ground  combat  within  Janus  is  known  as  the  Janus 
execution  module  and  is  unchanged  within  J6K  except  for  the  detection  algorithm  used  for  those 
combat  systems  using  their  sighting  systems  for  combat  actions.  The  change  uses  the  new 
algorithm  supplied  by  the  Army’s  Night  Vision  Laboratories  and  is  mandatory  for  all  new 
revisions  of  Janus. 

Janus  Version  6,  as  used  within  J6K,  has  a  V&V  history,  an  accreditation  history  for  analysis,  is 
under  configuration  control,  and  is  well  documented.  TRAC-WSMR  will  certify  to  JADS  that 
these  conditions  exist  and  that  the  Janus  execution  module  is  a  verified  and  validated 
representation  of  ground  combat  to  include  movement. 

This  certification  will  suffice  to  meet  the  following  acceptability  criteria:  The  simulation  has  a 
V&V  history,  an  accreditation  history  for  analysis,  is  under  configuration  control,  and  is  well 
documented. 

Area  coverage  and  attrition  for  area  weapons  will  be  representative  of  the  real  weapon  system. 
Unclassified  data  sets  will  be  used  for  the  ETE  Test  as  the  JADS  ETE  Test  is  not  testing  area 
weapon  effects.  The  simulation  must  be  capable  of  using  classified  data  sets  to  represent  actual 
weapons  effects  if  so  required. 

4.1.2  TAFSM 

TAFSM  is  a  verified  and  validated  simulation  of  a  theater-level  U.S.  Army  field  artillery  battle.  It 
has  been  accredited  for  use  in  combat  development  studies  such  as  COEAs  or  AOAs,  operational 
test  planning  and  post-test  studies,  and  training.  TAFSM  will  be  used  as  is  by  the  DSABL  and 
will  be  certified  as  representing  a  valid  simulation  of  the  U.S.  Army  field  artillery  battle. 

This  certification  will  suffice  to  meet  the  following  acceptability  criteria:  Simulation  must  be 
accredited  by  DSABL  for  use  in  representing,  in  a  doctrinally  correct  manner,  a  corps-level 
employment  of  ATACMS.  The  battle  lab  will  certify  that  the  representation  of  the  U.S.  Army 
field  artillery  battle  within  TAFSM  is  doctrinally  correct. 

Simulation  will  represent  the  performance  characteristics  of  the  ATACMS  in  a  matter  acceptable 
to  DSABL.  The  battle  lab  will  certify  that  the  performance  characteristics  of  the  ATACMS 
within  the  simulation  is  acceptable. 
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4.2  Additional  V&V  Activities  to  Be  Performed 


Additional  V&V  activities  must  be  performed  on  the  legacy  models,  J6K  and  TAFSM,  the  newly 
developed  VSTARS,  and  the  ETE  Test  SE.  These  additional  V&V  activities  will  be  associated 
with  the  acceptability  criteria  for  each  simulation  as  stated  earlier.  The  activities  will  be 
conducted  to  the  extent  required  to  satisfy  the  associated  acceptability  criteria,  as  time  and  funds 
allow,  and  will  be  described  in  detail  within  the  following  verification  and  validation  plans.  In 
addition,  components  of  the  ETE  Test  SE  environment,  such  as  network  interface  units,  will 
require  testing  to  determine  that  they  perform  correctly. 

4.2.1  J6K 

Verification  Requirements 

•  Verify  that  J6K  is  capable  of  simulating  at  least  5000  entities  with  at  least  twenty-five  percent 
moving  using  a  COTS  product  costing  less  then  100,000  dollars. 

•  Verify  that  J6K  issues  DIS  2.0.4  ESPDUs  that  conform  with  the  DIS  2.0.4  standards  as 
amended  by  JADS  as  to  content  and  format. 

•  Verify  that  J6K  will  receive  and  act  upon  each  ESPDU,  fire  PDU,  and  detonate  PDU  issued 
to  it  by  the  network  and  will  take  the  appropriate  action  as  dictated  by  the  PDU  provided  the 
appropriate  data  sets  regarding  the  PDU  have  been  entered  into  the  simulation. 

•  Verify  that  the  simulation  will  accept  and  process  scenarios  with  a  duration  longer  than  eight 
hours. 

•  Verify  that  the  operator  will  be  capable  of  fully  interacting  with  a  scenario  while  it  is  running. 

•  Verify  that  the  simulation  will  be  capable,  when  running,  of  proceeding  in  a  step-wise  fashion 
at  a  pace  representative  of  near  real  time.  That  is,  when  a  unit  of  game  time  is  represented 
within  Janus,  a  corresponding  amount  of  time  will  have  elapsed  since  the  start  of  the 
simulation.  This  feature  will  be  adjusted  by  tuning  the  scenario. 

•  Verify  that  the  simulation  will  be  capable  of  utilizing  scenarios  conducted  upon  terrain 
representing  a  simulation  area  of  at  least  200  km  by  200  km. 

Validation  Requirements 

•  Validate  that  J6K  represents  vehicle  behavior  to  the  degree  detectable  by  the  Joint  STARS 
operator(s).  This  capability  will  be  judged  based  upon  viewing  vehicle  movement  upon  the 
Joint  STARS  ATWS.  Joint  STARS  operator  SMEs  will  be  used  to  evaluate  these  criteria. 

4.2.2  TAFSM 
Verification  Requirement 

•  Verify  that  TAFSM  will  accept  artillery  missions  using  TACFIRE  or  AFATDS  messages 
encapsulated  in  a  DIS  PDU.  Simulation  will  issue  a  fire  and  detonate  PDU  whenever  an 
ATACMS  missile  is  fired  and  subsequently  detonated. 
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Validation  Requirement 

•  None  additional.  All  validation  requirements  for  TAFSM  are  already  met.  See  Paragraph 

4.1.2  TAFSM. 

4.2.3  VSTARS 

Verification  Requirements 

•  Verily  that  VSTARS  receives  virtual  target  data  from  the  JADS  JTF  ETE  Test  environment 
and  integrates  it  with  live  target  data  received  and  processed  by  the  radar  subsystem. 

•  Verify  that  for  MTI  reports,  VSTARS  operates  in  three  modes:  only  live  targets  displayed, 
mixed  live  and  virtual  targets  displayed,  and  only  virtual  targets  displayed.  Display  will  be 
upon  the  currently  installed  version  of  the  operator's  workstation. 

•  Verify  that  VSTARS  permits  the  SAR  report  to  consist  of  either  a  real  report  or  a  virtual 
report. 

•  Verify  that  in  all  modes  of  operation,  VSTARS  will  permit  all  of  the  installed  operator 
workstation  software  to  function  without  abnormal  fault  messages  occurring.  Abnormal  fault 
messages  are  defined  as  those  caused  specifically  by  the  use  of  VSTARS. 

•  Verify  that  VSTARS  presents  all  virtual  radar  results  using  the  standard  format  for  MTI  and 
SAR  reports  within  Joint  STARS  timelines  where  specified. 

Validation  Requirements 

•  Validate  that  for  the  MTI  reports,  virtual  targets  exhibit  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar.  Operational  behavior 
characteristics  of  the  virtual  targets  will  not  differ  noticeably  from  the  operational 
characteristics  of  real  targets.  The  operational  behavior  characteristics  will  be  evaluated 
visually. 

•  Validate  that  for  virtual  SAR  reports,  the  images  will  exhibit  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar.  In  addition,  virtual  SAR 
reports  will  exhibit  an  acceptable  degree  of  fidelity  matching  that  found  in  actual  images.  The 
fidelity  of  SAR  reports  will  be  evaluated  visually. 

4.2.4  Ground  Network  Interface  Unit  (GNIU) 

Test  Requirements 

•  The  GNIU  receives  and  processes  DIS  2.0.4  ESPDUs  from  the  ETE  Test  DIS  network  at  a 
rate  greater  than  350  ESPDUs  per  second. 

•  The  GNIU  determines  if  arriving  ESPDUs  are  within  VSTARS  area  of  interest.  For  those 
that  are,  the  GNIU  checks  to  see  if  the  ESPDU  represents  a  new  entity  or  a  change  in  velocity 
for  a  previously  received  entity,  and  passes  new  or  changed  entities  to  the  coordinate 
transform  routine. 
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•  The  GNIU  performs  a  coordinate  transform  upon  entities  selected  for  transmittal  to  the  ANIU 
and  prepares  a  VSTARS  data  packet  containing  all  entity  data  required  by  the  RPSI  for 
transmission  to  the  ANIU. 

•  The  VSTARS  data  packet  is  less  then  527  bits  and  the  total  bandwidth  requirements  for  the 
link  between  the  GNIU  and  ANIU  are  less  than  256  Kbits/sec. 

•  The  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity  state  of  the  E-8C  based  on 
data  received  from  the  ANIU. 

4.2.5  Air  Network  Interface  Unit  (ANIU) 

Test  Requirements 

•  The  ANIU  operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and 
hardware. 

•  The  ANIU  receives  and  processes  VSTARS  data  packets  at  a  rate  commensurate  with  a 
maxium  bandwidth  of  256  Kbits/sec. 

•  The  ANIU  stores  entity  data  received  in  an  ANIU  target  database. 

•  The  ANIU  conducts  dead  reckoning  upon  moving  targets  at  a  minimum  rate  of  1  Hz  and 
stores  revised  locations  in  the  ANIU  target  database. 

•  The  ANIU  provides,  from  the  navigational  update  message  available  from  the  navigation 
subsystem,  the  necessary  data  required  for  the  GNIU  to  construct  an  ESPDU. 

4.2.6  Radar  Processor  Simulator  and  Integrator  (RPSI)  Management  and  Integration 

Software  (M&IS) 

Verification  Requirements 

•  Verify  that  the  RPSI  M&IS  operates  upon  and  is  compatible  with  E-8C  onboard  operating 
systems  and  hardware. 

•  Verify  that  the  RPSI  M&IS  receives  the  details  of  a  radar  mission  from  the  radar  subsystem  as 
a  PSP  parameter  message  and  determines  if  it  is  a  MTI  or  SAR  mission  Determines  from  the 
PSP  parameter  message  the  coordinates  of  the  area  covered  by  the  mission,  and  retrieves  from 
the  ANIU  target  database  all  targets  that  are  located  within  the  area.  Appends  the  targets  to 
the  PSP  parameter  message  and  sends  them  to  the  appropriate  simulation  depending  upon 
mission  type. 

•  Verify  that  the  RPSI  M&IS,  for  MTI  radar  missions,  receives  the  outputs  from  the  radar 
processor  and  the  MTI  simulation  and  determines  the  appropriate  distribution  of  targets 
within  the  area  covered  by  the  mission,  based  on  mode  of  operation  (real,  virtual,  or  mixed). 

•  Verify  that  the  RPSI  M&IS  sends  the  composite  target  report  to  the  radar  post-processor. 

•  Verify  that  the  RPSI  M&IS,  for  SAR  missions,  receives  the  outputs  from  the  radar  processor 
and  ARIES  and  determines  if  the  mission  is  for  a  real  area  or  a  virtual  area. 

•  Verify  that  the  RPSI  M&IS  forwards  the  appropriate  report,  real  or  virtual,  to  the  radar  post¬ 
processor. 
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Validation  Requirements 

•  None  required. 

4.2.7  Moving  Target  Indicator  (MTI)  Radar  Simulation 

Verification  Requirements 

•  Verify  that  the  MTI  radar  simulation  operates  upon  and  is  compatible  with  E-8C  onboard 
operating  systems  and  hardware. 

•  Verify  that  the  MTI  radar  simulation  receives  PSP  parameter  messages  from  the  RPSI  M&IS. 

•  Verify  that  the  MTI  radar  simulation  performs  on  a  dwell  basis. 

•  Verify  that  the  MTI  radar  simulation  has  minimal  impact  upon  the  radar  timeline. 

Validation  Requirements 

•  Validate  that  the  MTI  radar  simulation  performs  the  necessary  functions  to  simulate  the  Joint 
STARS  MTI  signal  processing.  The  emulation  represents  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar  and  considers  environmental 
effects  that  affect  the  radar’s  performance. 

4.2.8  Advanced  Radar  Imaging  Emulation  System  (ARIES) 

Verification  Requirements 

•  Verify  that  ARIES  operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems  and 
hardware. 

•  Verify  that  ARIES  receives  a  PSP  parameter  message  from  the  RPSI  M&IS  and  performs  the 
functions  required  to  generate  a  Joint  STARS  SAR  image. 

•  Verify  that  ARIES  formats  the  image  information  into  the  proper  Joint  STARS  format  for 
transmittal  to  the  RPSI  M&IS  and  subsequent  transmittal  to  the  radar  post-processor. 

•  Verify  that  ARIES  has  minimal  impact  upon  the  radar  timeline. 

Validation  Requirements 

•  Validate  that  ARIES  represents  radar  performance  measures  as  defined  during  developmental 
testing  of  the  Joint  STARS  radar. 

•  Validate  that  ARIES  visually  matches  the  fidelity  of  Joint  STARS  SAR  images  as  determined 
by  ATWS  operators. 
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4.2.9  Programmable  Single  Processor  (PSP)  Simulation  (Laboratory  Only) 

Verification  Requirements 

•  Verify  that  the  PSP  simulation  receives  and  processes  radar  service  requests  from  the  O&C 
subsystem. 

•  Verify  that  the  PSP  simulation  requests  and  receives  navigation  information  from  the 
navigation  simulation. 

•  Verify  that  the  PSP  simulation  develops  and  issues  to  the  RPSI  M&IS,  a  PSP  parameter 
message  corresponding  to  a  specific  radar  service  request. 

Validation  Requirements 

•  Validate  that  the  PSP  simulation  simulates  the  performance  of  the  PSP  with  respect  to  the 
time  required  to  produce  the  PSP  parameter  message. 

4.2.10  Navigation  Simulation  (Laboratory  Only) 

Verification  Requirements 

•  Verify  that  the  navigation  simulation  provides  the  required  data,  reports  and  messages  to  the 
radar  subsystem  as  called  for  by  the  PSP  simulation 

Validation  Requirements 

•  Validate  that  the  navigation  simulation  simulates  the  position,  altitude  and  speed  of  an  E-8C 
aircraft  flying  a  specified  orbit. 

4.3  ETE  Test  Synthetic  Environment  (ETE  Test  SE) 

The  ETE  Test  SE  is  handled  differently,  with  respect  to  V&V,  than  the  individual  simulations  and 
interfaces  considered  above.  V&V  of  the  ETE  Test  SE  must  consider  the  grouping  of  the 
simulations  and  interfaces,  how  they  communicate,  and  the  condition  of  the  data  when  passed  and 
received.  As  stated  earlier,  the  DIS  Nine  Step  W&A  Process  Model  is  included  within  the  DoD 
W&A  Recommended  Practices  Guide  as  a  process  that  may  be  used  to  address  the  V&V  issues 
associated  with  the  ETE  Test  SE 

The  DIS  Nine  Step  Process  Model  consists  of  a  W&A  planning  step,  which  this  plan  represents 
for  V&V;  seven  V&V  steps;  and  an  accreditation  step,  which  will  be  addressed  in  a  separate  plan. 
The  required  V&V  steps  will  be  discussed  in  general  terms,  and  the  detailed  actions  required  will 
be  discussed  in  detail  in  the  appropriate  sections  of  the  verification  pPlan  that  follows. 
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Verification  Requirements 

The  verification  requirements  performed  will  verify 

•  that  the  latency  associated  with  each  PDU  will  be  small  enough  that  the  data  provided  by  the 
PDU  remain  valid  for  the  simulation  receiving  the  PDU. 

•  that  the  rate  of  PDUs  lost  or  corrupted  will  be  low  enough  for  each  type  of  PDU  that  the  ETE 
Test  SE  will  be  perceived  as  representing  reality. 

Perform  Conceptual  Model  Verification.  The  V&V  team  will  compare  the  conceptual 
model  for  the  SE  with  the  SE  requirements  to  determine  that  all 

•  required  processes  and  their  relationships  have  been  adequately  described; 

•  entity  requirements  have  been  defined  to  include  required  attributes  and  components  and 
both  dynamic  interactions  and  static  relationships  with  other  objects; 

•  input  data  requirements  and  authoritative  sources  have  been  identified;  and 

•  fidelity  requirements  have  been  specified. 

Perform  Compliance  Standards  Verification.  The  V&V  team  will  verify  that  a  model, 
simulation  or  simulator  complies  with  the  DIS  protocol  standard  as  implemented  within  the  JADS 
ETE  Test. 

Perform  Architectural  Design  Verification.  The  V&V  team  will  verify  that  the  developing 
architecture  accurately  reflects  the  SE  requirements  as  described  in  the  conceptual  model. 

Perform  Detailed  Design  Verification.  The  V&V  team  will  verify  that  the  SE  design 
continues  to  accurately  reflect  SE  requirements  and  is  adequate  to  support  the  anticipated 
activities. 

Perform  Compatibility  Verification  -  The  V&V  team  will  verify  that 

•  M&S  components  exchange  data  and  interact  appropriately  with  each  other; 

•  individual  components  correctly  use  the  common  data  (e.g.,  terrain,  weather)  to  generate 
their  portion  of  the  synthetic  environment;  and 

•  the  overall  implementation  is  adequate  to  address  the  exercise  requirements. 

Validation  Requirements 

The  validation  requirements  performed  will  validate 

•  that  the  end-to-end  sequence  is  conducted  in  a  doctrinally  correct  manner  using  the  ETE  Test 
SE. 
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that  near  real-time,  virtual  situational  awareness  is  provided  to  the  sensor  system  represented 
by  V STARS. 


Perform  Conceptual  Model  Validation.  The  V&V  team  will  validate  that  the  conceptual 
model  is  a  suitable  specification  for  simulation  design  of  the  SE  requirements  in  terms  of 

•  required  environments  and  scenarios; 

•  requisite  number  and  types  of  entities; 

•  required  entity  behaviors,  components,  attributes; 

•  interactions  between  entities; 

•  logical  context  of  required  processes;  and 

•  degree  of  fidelity  required. 

Perform  Validation.  The  V&V  team  will  validate  that  the  integrated  simulation  is  adequate 
to  satisfy  SE  requirements  such  that 

•  SE  behaviors  and  performance  map  sufficiently  to  real-world  counterparts  for  the  specific 
application; 

•  performances  and  representations  of  the  simulated  entities  are  sufficient  to  support  the 
intended  application;  and 

•  testing  has  been  done  to  address  acceptance  criteria. 
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5.0  Verification  Plan 


Verification  conducted  in  support  of  the  ETE  Test  will  occur  at  a  number  of  sites  and  will  be 
conducted  by  both  contractor  and  ETE  Test  team  personnel.  Prior  to  the  execution  of  each 
verification  task,  a  detailed  execution  plan  will  be  developed  and  submitted  to  the  ETE  Test 
manager  and  the  accreditation  agent  for  review  and  approval.  Similar  or  same  verification  tasks 
performed  on  a  simulation  will  normally  occur  simultaneously  and  share  a  common  execution 
plan. 

In  addition,  the  verification  of  the  ETE  Test  synthetic  environment  will  occur  both  during  Phase  2 
and  Phase  3.  This  is  necessitated  by  a  change  in  the  SE  when  VSTARS  is  moved  from  the 
laboratory  to  the  E-8C  aircraft.  The  second  time  the  ETE  Test  SE  is  verified,  the  primary  effort 
will  be  to  identify  changes  from  the  original  SE  and  to  concentrate  mainly  upon  those  changes,  if 
any,  and  their  effect  upon  the  SE. 

5.1  J6K 

a)  Verify  that  J6K  is  capable  of  simulating  at  least  5000  entities  with  at  least  twenty-five  percent 
moving  using  a  COTS  product  costing  less  then  100,000  dollars. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  an 
inspection  of  J6K.  The  inspection  will  consist  of  five  phases:  overview,  preparation, 
inspection,  rework,  and  follow-up.  This  inspection  will  take  place  during  Phase  lwith  a 
written  report  to  document  the  team’s  work. 

b)  Verify  that  J6K  issues  DIS  2.0.4  ESPDUs  that  conform  with  the  DIS  2.0.4  standards  as 
amended  by  JADS  as  to  content  and  format. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  an 
inspection  of  the  ESPDU  issued  by  J6K.  The  inspection  will  consist  of  the  five  phases 
previously  mentioned  and  occur  during  Phase  1  with  a  written  report  to  document  the  team’s 
work. 

c)  Verify  that  J6K  will  receive  and  act  upon  each  ESPDU,  fire  PDU,  and  detonate  PDU  issued 
to  it  by  the  network  and  will  take  the  appropriate  action  as  dictated  by  the  PDU  provided  the 
appropriate  data  sets  regarding  the  PDU  have  been  entered  into  the  simulation. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  several 
steps:  cause-effect  graphing,  acceptance  testing,  execution  monitoring,  functional  testing  and 
data  verification.  See  Appendix  C  for  a  description  of  each  of  these  steps.  Each  step  will 
consist  of  preparation,  step  execution,  rework  and  follow-up,  and  reporting.  This  task  will  be 
performed  during  Phase  2  with  a  written  report  to  document  the  team’s  work. 
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d)  Verify  that  the  simulation  will  accept  and  process  scenarios  with  a  duration  longer  than  eight 
hours. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  an 
inspection  of  J6K.  The  inspection  will  consist  of  five  phases:  overview,  preparation, 
inspection,  rework,  and  follow-up.  This  inspection  will  take  place  during  Phase  2  with  a 
written  report  to  document  the  team’s  work. 

e)  Verify  that  the  operator  will  be  capable  of  fully  interacting  with  a  scenario  while  it  is  running. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  an 
inspection  of  J6K.  The  inspection  will  consist  of  five  phases:  overview,  preparation, 
inspection,  rework,  and  follow-up.  This  inspection  will  take  place  during  Phase  2  with  a 
written  report  to  document  the  team’s  work. 

f)  Verify  that  the  simulation  will  be  capable,  when  running,  of  proceeding  in  a  step-wise  fashion 
at  a  pace  representative  of  near  real  time.  That  is,  when  a  unit  of  game  time  is  represented 
within  Janus,  a  corresponding  amount  of  time  will  have  elapsed  since  the  start  of  the 
simulation.  This  feature  will  be  adjusted  by  tuning  the  scenario. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  the 
execution  monitoring  of  J6K.  The  execution  monitoring  will  consist  of  preparation,  step 
execution,  rework  and  follow-up,  and  reporting.  This  task  will  be  performed  during  Phase  2 
with  a  written  report  to  document  the  teams  work.  This  inspection  also  will  take  place  for 
each  scenario  developed  for  J6K  with  a  written  report  to  document  the  team’s  work. 

g)  Verify  that  the  simulation  will  be  capable  of  utilizing  scenarios  conducted  upon  terrain 
representing  a  simulation  area  of  at  least  200  km  by  200  km. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  an 
inspection  of  J6K.  The  inspection  will  consist  of  five  phases:  overview,  preparation, 
inspection,  rework,  and  follow-up.  This  inspection  will  take  place  during  Phase  2  with  a 
written  report  to  document  the  team’s  work. 

5.2  TAFSM 

a)  Verify  that  TAFSM  will  accept  artillery  missions  using  TACFIRE  or  AFATDS  messages 
encapsulated  in  a  DIS  PDU.  Simulation  will  issue  a  fire  and  detonate  PDU  whenever  an 
ATACMS  missile  is  fired  and  subsequently  detonated. 

This  verification  task  will  be  performed  by  the  ETE  Test  V&V  team  and  will  consist  of  several 
steps:  cause-effect  graphing,  acceptance  testing,  execution  monitoring,  functional  testing  and 
data  verification.  See  Appendix  C  for  a  description  of  each  of  these  steps.  Each  step  will 
consist  of  preparation,  step  execution,  rework  and  follow-up,  and  reporting.  This  task  will  be 
performed  during  Phase  2  with  a  written  report  to  document  the  team’s  work. 
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5.3  VSTARS 


The  verification  and  testing  of  VSTARS  will  be  conducted  by  Northrop  Grumman  and  the  Joint 
STARS  JTF  during  Phase  2  of  the  ETE  Test.  Northrop  Grumman  will  develop  a  separate  V&V 
plan  for  VSTARS  (Appendix  A)  and  submit  this  plan  to  the  ETE  Test  manager  for  comment  and 
approval.  Verification  and  test  tasks  will  be  performed  by  Northrop  Grumman  and  the  Joint 
STARS  JTF  with  JADS  ETE  Test  V&V  team  oversight.  During  Phase  1,  VSTARS  will  undergo 
acceptance  testing  as  a  prerequisite  for  moving  to  Phase  2.  The  test  plan  will  be  developed  by 
Northrop  Grumman  (Appendix  A)  and  submitted  to  the  ETE  Test  manager  for  comment  and 
approval.  Acceptance  testing  will  be  performed  by  Northrop  Grumman  with  oversight  by  the 
ETE  Test  V&V  team  and  will  be  successfully  completed  prior  to  Phase  2  activities  involving 
VSTARS. 

In  addition,  an  acceptance  test  of  the  ground  data  terminal  1553  bus  interface  unit  software  will 
be  conducted  during  Phase  1  by  Motorola,  the  developer  of  the  software.  Motorola  will  develop 
a  test  plan  (Appendix  B)  and  submit  it  to  the  ETE  Test  manager  for  comment  and  approval.  The 
software  test  will  be  performed  by  Motorola,  with  Northrop  Grumman  assistance  and  JADS  ETE 
Test  V&V  team  oversight.  A  report  detailing  the  results  of  the  acceptance  test  will  be  submitted 
to  the  ETE  Test  manager. 

5.3.1  Verification  Tasks  to  be  Performed  on  the  VSTARS  Simulation 

•  Verify  that  VSTARS  receives  virtual  target  data  from  the  JADS  JTF  ETE  Test 
environment  and  integrates  it  with  live  target  data  received  and  processed  by  the  radar 
subsystem. 

•  Verify  that  for  MTI  reports,  VSTARS  operates  in  three  modes:  only  live  targets 
displayed,  mixed  live  and  virtual  targets  displayed,  and  only  virtual  targets  displayed. 
Display  will  be  upon  the  currently  installed  version  of  the  operator's  workstation. 

•  Verify  that  VSTARS  permits  the  SAR  report  to  consist  of  either  a  real  report  or  a  virtual 
report. 

•  Verify  that  in  all  modes  of  operation,  VSTARS  will  permit  all  of  the  installed  operator 
workstation  software  to  function  without  abnormal  fault  messages  occurring.  Abnormal 
fault  messages  are  defined  as  those  caused  specifically  by  the  use  of  VSTARS. 

•  Verify  that  VSTARS  presents  all  virtual  radar  results  using  the  standard  format  for  MTI 
and  SAR  reports. 
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5. 3. 1. 1  Ground  Network  Interface  Unit  ( GNIU) 

•  Test  that  the  GNIU  receives  and  processes  DIS  2.0.4  ESPDU  from  the  ETE  Test  DIS 
network  at  a  rate  greater  than  350  ESPDU  per  second. 

•  Test  that  the  GNIU  determines  if  arriving  ESPDUs  are  within  VSTARS  area  of  interest. 
For  those  that  are,  test  that  the  GNIU  checks  to  see  if  the  ESPDU  represents  a  new  entity 
or  a  change  in  velocity  for  a  previously  received  entity  and  passes  new  or  changed  entities 
to  the  coordinate  transform  routine. 

•  Test  that  the  GNIU  performs  a  coordinate  transform  upon  entities  selected  for  transmittal 
to  the  ANIU  and  prepares  a  VSTARS  data  packet,  containing  all  entity  data  required  by 
the  RPSI  for  transmission  to  the  ANIU. 

•  Test  that  the  VSTARS  data  packet  is  less  then  527  bits  and  that  the  total  bandwidth 
requirements  for  the  link  between  the  GNIU  and  ANIU  are  less  than  256  Kbits/sec. 

•  Test  that  the  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity  state  of  the  E- 
8C  based  on  data  received  from  the  ANIU. 

5.3. 1.2  Air  Network  Interface  Unit  (ANIU) 

•  Test  that  the  ANIU  operates  upon  and  is  compatible  with  E-8C  onboard  operating 
systems  and  hardware. 

•  Test  that  the  ANIU  receives  and  processes  VSTARS  data  packets  at  a  rate  commensurate 
with  a  maximum  bandwidth  of  256  Kbits/sec. 

•  Test  that  the  ANIU  stores  entity  data  received  in  an  ANIU  target  database. 

•  Test  that  the  ANIU  conducts  dead  reckoning  upon  moving  targets  at  a  minimum  rate  of  1 
Hz  and  stores  revised  locations  in  the  ANIU  target  database. 

•  Test  that  the  ANIU  provides,  from  the  navigational  update  message  available  from  the 
navigation  subsystem,  the  necessary  data  required  for  the  GNIU  to  construct  an  ESPDU. 

5.3.1. 3  Radar  Processor  Simulation  and  Integrator  (RPSI)  Management  and  Integration 

Software  (M&IS) 

•  Verify  that  the  RPSI  M&IS  operates  upon  and  is  compatible  with  E-8C  onboard  operating 
systems  and  hardware. 
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•  Verify  that  the  RPSI  M&IS  receives  the  details  of  a  radar  mission  from  the  radar 
subsystem  as  a  PSP  parameter  message  and  determines  if  it  is  a  MTI  or  SAR  mission. 
Determine  from  the  PSP  parameter  message  the  coordinates  of  the  area  covered  by  the 
mission  and  retrieves  from  the  ANIU  target  database  all  targets  that  are  located  within  the 
area.  Append  the  targets  to  the  PSP  parameter  message  and  sends  them  to  the  appropriate 
simulation  depending  upon  mission  type. 

•  Verify  that  the  RPSI  M&IS,  for  MTI  radar  missions,  receives  the  outputs  from  the  radar 
processor  and  the  MTI  simulation  and  determines  the  appropriate  distribution  of  targets 
within  the  area  covered  by  the  mission  based  on  mode  of  operation  (real,  virtual,  or 
mixed). 

•  Verify  that  the  RPSI  M&IS  sends  the  composite  target  report  to  the  radar  post-processor. 

•  Verify  that  the  RPSI  M&IS,  for  SAR  missions,  receives  the  outputs  from  the  radar 
processor  and  ARIES  and  determines  if  the  mission  is  for  a  real  area  or  a  virtual  area. 

•  Verify  that  the  RPSI  M&IS  forwards  the  appropriate  report,  real  or  virtual,  to  the  radar 
post-processor. 

5. 3. 1.4  Moving  Target  Indicator  (MTI)  Radar  Simulation 

•  Verify  that  the  MTI  radar  simulation  operates  upon  and  is  compatible  with  E-8C  onboard 
operating  systems  and  hardware. 

•  Verify  that  the  MTI  radar  simulation  receives  PSP  parameter  messages  from  the  RPSI 
M&IS. 

•  Verify  that  the  MTI  radar  simulation  performs  on  a  dwell  basis. 

•  Verify  that  the  MTI  radar  simulation  has  minimal  impact  upon  the  radar  timeline. 

5.3. 1.5  Advanced  Radar  Imaging  Emulation  System  (ARIES) 

•  Verify  that  Aries  operates  upon  and  is  compatible  with  E-8C  onboard  operating  systems 
and  hardware. 

•  Verify  that  ARIES  receives  a  PSP  parameter  message  from  the  RPSI  M&IS  and  performs 
the  functions  required  to  generate  a  Joint  STARS  SAR  image. 

•  Verify  that  ARIES  formats  the  image  information  into  the  proper  Joint  STARS  format  for 
transmittal  to  the  RPSI  M&IS  and  subsequent  transmittal  to  the  radar  post-processor. 

•  Verify  that  ARIES  has  minimal  impact  upon  the  radar  timeline. 
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5.3.1. 6  Programmable  Single  Processor  (PSP)  Simulation  (Laboratory  Only) 

•  Verify  that  the  PSP  simulation  receives  and  processes  radar  service  requests  from  the 
O&C  subsystem. 

•  Verify  that  the  PSP  Simulation  requests  and  receives  navigation  information  from  the 
navigation  simulation. 

•  Verify  that  the  PSP  Simulation  develops  and  issues  to  the  RPSI  M&IS,  a  PSP  parameter 
message  corresponding  to  a  specific  radar  service  request. 

5. 3. 1.7  Navigation  Simulation  (Laboratory  Only) 

•  Verify  that  the  navigation  simulation  provides  the  required  data,  reports  and  messages  to 
the  radar  subsystem  as  called  for  by  the  PSP  simulation. 

5.4  ETE  Test  Synthetic  Environment  (ETE  Test  SE) 

The  remaining  verification  of  the  ETE  Test  SE  will  be  performed  by  the  ETE  Test  V&V  team 
during  Phases  2  and  3  of  the  JADS  ETE  Test.  As  indicated  in  Figure  2  many  of  the  verification 
tasks  required  to  be  performed  have  been  performed  earlier  in  the  planning  of  the  ETE  Test. 
Execution  of  these  verification  steps  will  consist  of  documenting  those  steps  already  performed. 

a)  Perform  Compliance  Standards  Verification  (Step  2) 

Initial  compliance  standards  verification  was  performed  during  the  development  of  the  program 
test  plan.  At  this  time  the  models  and  simulations  identified  for  use  in  the  ETE  Test  SE  were 
verified  by  inspection  as  meeting  DIS  compliance  standards  to  the  extent  required.  Completion  of 
this  initial  compliance  standards  verification  will  consist  of  reporting  on  the  steps  performed 
during  the  development  of  the  PTP. 

Further  compliance  standards  verification  will  be  performed  during  Phase  2  and  Phase  3  of  the 
ETE  Test  and  will  consist  of  an  inspection  of  a  sampling  of  PDUs  emitted  by  each  simulation  to 
ensure  proper  adherence  to  the  prescribed  format.  The  inspection  will  consist  of  five  phases: 
overview,  preparation,  inspection,  rework,  and  follow-up  with  a  written  report  to  document  the 
team’s  work.  In  addition,  a  model  interface  analysis  of  the  SE  will  be  conducted  to  determine  if 
the  submodels  within  the  SE  are  correctly  communicating  using  DIS  PDUs.  The  interface 
analysis  will  consist  of  four  phases:  preparation,  data  collection,  analysis,  and  reporting  with  a 
written  report  to  document  the  team’s  work. 

b)  Perform  Conceptual  Model  Verification  (Step  3) 

The  conceptual  model  verification  was  performed  during  the  development  of  the  feasibility  study. 
At  that  time,  several  conceptual  models  were  verified  by  inspection  and  one  was  chosen  for 
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further  development  into  the  ETE  Test  SE.  Completion  of  the  conceptual  model  verification  will 
consist  of  documenting  the  conceptual  models  considered  and  the  verification  steps  taken. 

c)  Perform  Architectural  Design  Verification  (Step  4) 

The  architectural  design  verification  was  performed  during  the  development  of  the  PTP.  It 
consisted  of  a  document  review,  the  development  of  a  preliminary  model  of  the  SE,  an  allocation 
of  functions  and  capabilities  to  the  nodes  of  the  SE,  operational  requirements  mapping,  a 
determination  of  interface  requirements  and  database  requirements,  and  initial  personnel  and  test 
requirements.  Completion  of  the  architectural  design  verification  will  consist  of  documenting  the 
verification  steps  taken. 

d)  Perform  Detailed  Design  Verification  (Step  5) 

The  detailed  design  verification  will  be  performed  by  the  ETE  Test  V&V  team  during  Phase  1  of 
the  ETE  Test.  As  the  detailed  design  evolves,  the  V&V  team  will 

•  review  M&S  component  documentation  and,  if  necessary,  source  code  to  determine 
component  ability  to  perform  their  assigned  functions; 

•  execute  key  algorithms  to  ensure  they  function  appropriately  to  address  the  exercise 
requirements; 

•  assess  the  logic  of  the  proposed  interconnections  of  the  components  by  evaluating  the 
proposed  interchange  of  PDUs;  and, 

•  analyze  the  exercise  design  for  its  rigor. 

Members  of  the  team  conducting  data  verification  and  validation  should  evaluate  the 
appropriateness  and  sufficiency  of  the  input  data  selected  for  use  in  the  exercise. 

This  activity  involves  five  major  tasks:  evaluate  detailed  design,  evaluate  interface  design,  verify 
data  and  databases,  evaluate  V&V  test  plans,  and  evaluate  training  requirements. 

Evaluate  Detailed  Design:  This  task  will  be  performed  by  inspection  and  will  determine  if  the 
design  is  sufficient  to  ensure 

•  the  individual  M&S  components  are  capable  of  representing  the  exercise  phenomenology  at 
appropriate  levels  of  resolution; 

•  the  underlying  network  assets  can  support  the  exchange  data  between  the  components  at  the 
necessary  levels  of  fidelity. 

Evaluate  Interface  Design:  This  task  will  be  performed  by  inspection  and  will  evaluate  the 
ability  of  the  individual  M&S  components  to  interoperate  with  each  other  and  with  the  network 
by 

•  determining  that  interfaces  among  components  and  interfaces  with  the  synthetic  environment 
are  adequate  and  sufficient  to  allow  consistency  in  the  level  of  details,  data  fidelity,  and  data 
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sources,  and  sufficient  modes  of  operation; 

•  ensuring  that  user  interfaces  for  input  and  output  can  pass  information  to  accomplish  efficient 
scenario  construction,  component  execution,  network  management,  and  report  generation  and 

•  evaluating  the  impact  of  network  factors  such  as  latency  produced,  network  loading,  and 
filtering  requirements. 

Verify  Data  and  Databases:  This  task  will  be  performed  by  inspection  and  will  assess  the 
adequacy,  sufficiency,  and  usability  of  the  input  data  and  databases.  It  will  be  accomplished  in 
conjunction  with  evaluate  detailed  design  and  evaluate  interface  design  to  ensure  the  data  required 
by  the  M&S  components  and  the  DIS  exercise  will  provide  appropriate,  consistent,  and  timely 
results  during  execution. 

Evaluate  V&V  Test  Plans:  This  task  will  be  accomplished  by  inspection  to  ensure  V&V  test 
plans  are  adequate  and  complete. 

Evaluate  Training  Requirements:  This  task  will  be  accomplished  by  inspection  and  will  consist 
of  reviewing  training  requirements,  assessing  the  ability  of  training  plans  to  address  the 
requirements,  and  recommending  appropriate  tests  for  evaluating  the  success  of  the  training. 

e)  Perform  Compatibility  Verification  (Step  6) 

The  compatibility  verification  will  be  performed  by  the  ETE  Test  V&V  team  during  Phase  2  of 
the  ETE  Test.  The  compatibility  verification  will  complete  the  verification  of  the  ETE  Test  SE  by 
ensuring 

•  M&S  components  exchange  data  and  interact  appropriately  with  each  other; 

•  individual  components  correctly  use  the  common  data  (e.g.,  terrain,  weather)  to  generate  their 
portion  of  the  synthetic  environment;  and 

•  the  overall  implementation  is  adequate  to  address  the  exercise  requirements. 

This  activity  involves  five  major  tasks:  evaluate  design  versus  implementation,  evaluate 
compatibility,  evaluate  interface  implementation,  assess  instrumentation  requirements,  evaluate 
impact  of  operator  proficiency. 

Evaluate  Design  Versus  Implementation:  This  task  will  be  performed  by  inspection  and  will 
determine  if  the  design  is  sufficient  to  ensure  the  adequacy  of  the  overall  implementation  by 
comparing  the  design  as  documented  (e.g.,  conceptual  model,  component  compliance  profiles  and 
fidelity  characterizations)  and  the  exercise  configuration.  The  V&V  team  will  participate  in 
exercise  development  walk-throughs  and  apply  a  series  of  checks  to  compare  the  physical 
configuration  to  the  documented  design.  In  addition,  functional  testing  will  be  applied  to  assess 
the  SE  performance  over  the  course  of  the  test. 

Evaluate  Compatibility:  This  task  will  be  performed  by  inspection  to  determine  if  the  individual 
components 

•  represent  system  performance  as  required  for  the  exercise; 
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•  transfer  information  to  and  from  the  network  without  corruption; 

•  share  common  perspectives  of  the  virtual  reality  produced  by  the  exercise;  and 

•  employ  database  elements,  shared  models  and  support  systems  appropriately. 

Evaluate  Interface  Implementation:  This  task  focuses  on  network  performance  needs, 
interface  implementation  issues,  and  identification  of  changes  in  the  exercise  configuration  that 
could  impact  operation  of  the  network.  The  V&V  team  will  inspect  the  hardware  configuration 
and  review  data  collection  and  transfer  (e.g.,  PDUs)  among  components  to  determine  that  the 
interface  implementation  is  in  accordance  with  interface  specifications.  The  V&V  team  will  also 
evaluate  the  results  of  network  loading  and  latency  tests  for  possible  impacts  on  simulation 
results. 

Assess  Instrumentation  Requirements:  The  V&V  team  will  evaluate  the  adequacy  of  the 
instrumentation  requirements  for  V&V  purposes. 

Evaluate  Impact  of  Operator  Proficiency:  The  V&V  team,  in  association  with  identified 
SMEs,  will  observe  and  evaluate  the  performance  of  operators  to  determine  if  they  possess  the 
appropriate  skill  level  to  perform  the  functions  required  for  the  test. 
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6.0  Validation  Plan 


Validation  conducted  in  support  of  the  ETE  Test  will  occur  at  a  number  of  sites  and  will  be 
conducted  by  both  contractor  and  ETE  Test  Team  personnel.  Prior  to  the  execution  of  each 
validation  task,  a  detailed  execution  plan  will  be  developed  and  submitted  to  the  ETE  Test 
manager  and  the  accreditation  agent  for  review  and  approval.  Similar  or  same  validation  tasks 
performed  on  a  simulation  will  normally  occur  simultaneously  and  share  a  common  execution 
plan. 

In  addition,  the  validation  of  the  ETE  Test  synthetic  environment  will  occur  both  during  Phase  2 
and  Phase  3.  This  is  necessitated  by  a  change  in  the  SE  when  VSTARS  is  moved  from  the 
laboratory  to  the  E-8C  aircraft.  The  second  time  the  ETE  Test  SE  is  validated,  the  primary  effort 
will  be  to  identify  changes  from  the  original  SE  and  to  concentrate  mainly  upon  those  changes,  if 
any,  and  their  effect  upon  the  SE. 

6.1  J6K 

Validate  that  J6K  represents  vehicle  behavior  to  the  degree  detectable  by  the  Joint  STARS.  This 
capability  will  be  judged  based  upon  viewing  vehicle  movement  upon  the  Joint  STARS  operator 
workstation.  Joint  STARS  operator  SMEs  will  be  used  to  evaluate  these  criteria. 

This  validation  task  will  be  performed  by  the  ETE  Test  V&V  team,  assisted  by  Northrop 
Grumman  and  SMEs  from  the  Joint  STARS  Joint  Test  Force.  Methodologies  used  for  this 
validation  will  include  inspection,  cause-effect  graphing,  comparison  testing  (bench-marking),  and 
Turing  testing.  The  validation  will  occur  during  Phase  2  and  be  repeated  during  Phase  3  with  a 
written  report  to  document  the  team’s  work. 

6.2  TAFSM 

No  additional  validation  tasks  are  required  specifically  for  TAFSM.  However,  when  the  ETE 
Test  SE  is  validated,  TAFSM,  as  a  part  of  the  ETE  Test  SE,  will  be  validated  within  the  context 
of  the  SE. 

6.3  VSTARS 

Except  for  ARIES,  the  validation  of  VSTARS  will  be  conducted  by  Northrop  Grumman  and  the 
Joint  STARS  JTF.  The  validation  will  occur  during  Phase  2  and  will,  by  necessity,  be  conducted 
within  the  context  of  the  SE.  Northrop  Grumman  will  prepare  a  separate  V&V  plan  for  VSTARS 
and  will  submit  this  plan  to  the  ETE  Test  manager  for  comment  and  approval.  Validation  tasks 
will  be  performed  by  Northrop  Grumman  and  the  Joint  STARS  JTF  with  JADS  ETE  Test  V&V 
team  oversight.  The  validation  of  ARIES  will  be  conducted  by  Lockheed  Martin  working  with 
Northrop  Grumman  and  the  Joint  STARS  JTF.  Lockheed  Martin  will  develop  a  separate  V&V 
plan  for  ARIES  and  submit  this  plan  to  the  ETE  Test  manager  for  comment  and  approval. 
Validation  tasks  will  be  performed  by  Lockheed  Martin  with  Northrop  Grumman  and  the  Joint 
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STARS  JTF  assistance  and  with  JADS  ETE  Test  V&V  team  oversight.  Following  the  installation 
of  VSTARS  upon  the  aircraft,  the  validation  will  be  checked  to  ensure  that  no  changes  have 
occurred  in  the  radar  products.  The  following  validation  tasks  will  be  performed. 

•  Validate  that  for  the  MTI  reports,  virtual  targets  exhibit  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar.  Operational  behavior 
characteristics  of  the  virtual  targets  shall  not  differ  noticeably  from  the  operational 
characteristics  of  real  targets.  The  operational  behavior  characteristics  will  be  evaluated 
visually. 

•  Validate  that  for  virtual  SAR  reports,  the  images  will  exhibit  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar.  In  addition,  virtual  SAR 
reports  will  exhibit  an  acceptable  degree  of  fidelity  matching  that  found  in  actual  images.  The 
fidelity  of  SAR  reports  will  be  evaluated  visually. 

Moving  Target  Indicator  (MTI)  Radar  Simulation 

•  Validate  that  the  MTI  radar  simulation  performs  the  necessary  functions  to  emulate  the  Joint 
STARS  MTI  signal  processing.  The  emulation  represents  radar  performance  measures  as 
defined  during  developmental  testing  of  the  Joint  STARS  radar  and  considers  environmental 
effects  that  affect  the  radar’s  performance. 

Advanced  Radar  Imaging  Emulation  System  (ARIES) 

•  Validate  that  ARIES  represents  radar  performance  measures  as  defined  during  developmental 
testing  of  the  Joint  STARS  radar. 

•  Validate  that  ARIES  visually  matches  the  fidelity  of  Joint  STARS  SAR  images  as  determined 
by  ATWS  operators. 

Programmable  Single  Processor  (PSP)  Simulation  (Laboratory  Only) 

•  Validate  that  the  PSP  simulation  emulates  the  performance  of  the  PSP  with  respect  to  the  time 
required  to  produce  the  PSP  parameter  message. 

Navigation  Simulation  (Laboratory  Only) 

•  Validate  that  the  navigation  simulation  simulates  the  position,  altitude  and  speed  of  an  E-8C 
aircraft  flying  a  specified  orbit. 

6.4  ETE  Test  Synthetic  Environment  (ETE  Test  SE) 

The  remaining  validation  of  the  ETE  Test  SE  will  be  performed  by  the  ETE  Test  V&V  team 
during  Phases  2  and  3  of  the  JADS  ETE  Test.  As  indicated  in  Figure  2  the  validation  task, 
perform  conceptual  model  validation,  was  performed  during  the  JADS  feasibility  study. 
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a)  Perform  Conceptual  Model  validation  (Step  3) 

The  conceptual  model  validation  was  performed  during  the  development  of  the  feasibility  study. 
At  this  time,  several  conceptual  models  were  validated  by  inspection  and  one  was  chosen  for 
further  development  into  the  ETE  Test  SE.  Completion  of  the  conceptual  model  validation  will 
consist  of  documenting  the  conceptual  models  considered  and  the  validation  steps  taken. 

B)  Perform  Validation  (Step  7) 

The  final  validation  of  the  ETE  Test  SE  will  be  performed  by  the  ETE  Test  V&V  team  assisted  by 
Northrop  Grumman  and  the  Joint  STARS  JTF  during  Phase  2  of  the  ETE  Test. 

The  validation  of  the  ETE  Test  SE  is  intended  to  ensure  that  the  integrated  simulation  is  adequate 
to  satisfy  the  ETE  Test  requirements  such  that 

•  SE  behaviors  and  performance  map  sufficiently  to  real-world  counterparts  for  the  specific 
application; 

•  performances  and  representations  of  the  simulated  entities  are  sufficient  to  support  the 
intended  application;  and 

•  testing  has  been  done  to  address  acceptance  criteria. 

This  activity  consists  of  five  basic  tasks:  establish  context  for  validation  activities,  evaluate 
configuration  interoperability,  assess  exercise  test  environment,  determine  validation  results,  and 
evaluate  operator  performance. 

Establish  Context  for  Validation  Activities:  The  purpose  of  this  task  is  to  confirm  the 
appropriateness  of  the  validation  effort,  affirm  the  availability  of  correct  data,  and  lay  the 
foundation  for  the  exercise  validation  report.  The  V&V  team  will  determine  that  the  scope  of  the 
validation  effort  is  adequate,  the  acceptability  criteria  are  sufficient,  and  potential  shortcomings 
and  limitations  are  identified. 

Evaluate  Configuration  Interoperability:  The  purpose  of  this  task  is  to  verify  the  mapping  of 
individual  components  to  the  detailed  design.  As  problem  areas  are  identified  during  testing,  the 
V&V  team  can  use  this  mapping  as  an  interoperability  blueprint  for  SE  integration  and 
implementation  to  pinpoint  potential  sources  of  difficulty. 

Perform  Effectiveness  Evaluation:  The  purpose  of  this  task  is  to  assess  the  ability  of  the 
different  parts  of  the  SE  architecture  (including  live  and  computer  generated  forces)  to  generate 
the  data  needed  to  address  the  acceptability  criteria.  This  task  will  involve 

•  tracing  exercise  performance  data  to  the  acceptability  criteria; 

•  evaluating  the  data  for  accuracy,  sufficiency,  and  appropriateness;  and 

•  testing  the  algorithms  used  to  collect,  aggregate  or  summarize  the  exercise  data  to  ensure  the 
resulting  values  are  accurate. 
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Evaluate  Test  Results:  The  V&V  team  will  test  the  SE  and  compare  the  SE  to  the  real  world 
represented  by  the  SE.  This  validation  task  will  be  performed  by  the  ETE  Test  V&V  team, 
assisted  by  Northrop  Grumman  and  SMEs  from  the  Joint  STARS  JTF.  Methodologies  used  for 
this  validation  will  include  inspection,  cause-effect  graphing,  comparison  testing  (benchmarking), 
and  Turing  testing.  The  validation  will  occur  during  Phase  2  and  be  repeated  during  Phase  3.  It 
will  produce  a  written  report  to  document  the  team’s  work. 

When  conducting  comparisons,  the  V&V  team  will  consider  underlying  assumptions,  differences 
in  fidelity,  and  other  constraints  and  limitations  in  their  evaluation.  Typical  issues  that  will  be 
addressed  include 

•  correspondence  between  SE  performance  and  real-world  behavior  and  appearance  of  the 
represented  systems  and  forces  (to  the  degree  required); 

•  suitability  of  the  correlation  of  fidelity  among  the  components; 

•  adequacy  of  the  environmental  representation;  and 

•  correlation  of  live  and  synthetic  targets. 

If  test  results  differ  widely  from  the  expected  values,  the  V&V  team  will  identify  the  causes  and 
report  them  to  the  ETE  Test  manager  and  appropriate  M&S  providers  for  resolution. 

Evaluate  Operator  Performance:  The  V&V  team  will  compare  the  operator  performance 
throughout  the  test  period  to  real-world  performance  requirements  and  report  deficiencies  that 
may  impact  the  validity  of  the  exercise  to  the  ETE  Test  manager. 
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7.0  Integrated  Verification  and  Validation 

The  following  integrated  schedule  and  resource  summary  will  be  utilized  to  conduct  the  V&V  of 
the  ETE  Test.  The  schedule  is  dependent  upon  the  ETE  Test  master  schedule  and,  as  changes 
occur  to  the  master  schedule,  the  V&V  schedule  will  also  change. 

7.1  ETE  Test  V&V  Schedule 


The  ETE  Test  schedule  is  shown  in  Figure  4.  The  task  names  refer  to  the  subparagraphs 
describing  the  V&V  tasks  listed  in  Sections  5  and  6. 
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7 
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Figure  4.  ETE  Test  V&V  Schedule 
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7.2  Resource  Summary 


ID 

Resource  Name 

97 

1998 

m 

Qtr3 

Qtr  4 

Qtr  1 

Qtr  2 

Qtr  3 

Qtr  4 

Qtr  1 

Qtr  2 

1 

Marchand 

60h 

41.28h 

165.2h 

91.83h 

120.95h 

15.2h 

55. 2h 

2 

Hovey 

17.28h 

43.18h 

51.83h 

120.95h 

15.2h 

55. 2h 

3 

Houser 

17.28h 

43.18h 

51.83h 

120.95h 

15.2h 

55.2h 

4 

Tapia 

51.83h 

120.95h 

38.4h 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 
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8.0  Acronyms  and  Abbreviations 


ACE 

ADS 

AFATDS 

ALSP 

ANIU 

AoA 

ARIES 

ASAS 

ATACMS 

ATWS 

C4I 

C4ISR 

CEP 

CGS 

COEA 

COTS 

D&ABL 

DIS 

DMSO 

DoD 

EMF 

ES 

ES  PDU 

ETE 

FCE 

GNIU 

GSM 

HLA 

Hz 

IEEE 

J6K 

JADS 

Janus 

Joint  STARS 

JT&E 

JTF 

Kbits/sec 

km 

LGSM 

M&IS 

M&S 


analysis  and  control  element 

advanced  distributed  simulation 

Advanced  Field  Artillery  Tactical  Data  System 

aggregate  level  simulation  protocol 

air  network  interface  unit 

analysis  of  alternatives 

Advanced  Radar  Imaging  Emulation  System 

All  Source  Analysis  System 

Army  Tactical  Missile  System 

Advanced  Technology  Work  Station 

command,  control,  communications,  computers  and  intelligence 

command,  control,  communications,  computers,  intelligence, 

surveillance  and  reconnaissance 

circular  error  probability 

common  ground  station 

cost  and  operational  effectiveness  analysis 

commercial  off-the-shelf 

Depth  and  Simultaneous  Attack  Battle  Lab 

distributed  interactive  simulation 

Defense  Modeling  and  Simulation  Organization,  Alexandria,  Virginia 

Department  of  Defense 

exercise  management  and  feedback 

entity  state 

entity  state  protocol  data  unit 
End-to-End  Test 
fire  control  element 
ground  network  interface  unit 
ground  station  module 
high  level  architecture 
hertz 

Institute  of  Electrical  and  Electronics  Engineers 

Janus  version  6  simulation  with  thousands  of  entities 

Joint  Advanced  Distributed  Simulation,  Albuquerque,  New  Mexico 

interactive,  computer-based  simulation  of  combat  operations 

Joint  Surveillance  Target  Attack  Radar  System 

joint  test  and  evaluation 

joint  test  force 

kilobits  per  second 

kilometer 

light  ground  support  module 
management  and  integration  software 
modeling  and  simulation 
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MPDU 

message  protocol  data  unit 

MTI 

moving  target  indicator 

O&C 

operations  and  control 

PDU 

protocol  data  unit 

PSP 

programmable  signal  processor 

PIP 

program  test  plan 

RPSI 

radar  processor  simulation  developed  by  Northrop  Grumman, 
Melbourne,  Florida 

SAR 

synthetic  aperture  radar 

SE 

synthetic  environment 

SME 

subject  matter  experts 

SOW 

statement  of  work 

SSE 

synthetic  subenvironments 

STRICOM 

U.S.  Army  Simulation,  Training  and  Instrumentation  Command 

TACFIRE 

tactical  fire 

TAFSM 

Tactical  Army  Fire  Support  Model 

TBD 

to  be  determined 

TCAC 

Test  Control  and  Analysis  Center 

TED 

terrain  editor 

TEL 

transporter,  erector,  launcher 

TEMP 

test  and  evaluation  master  plan 

TRAC 

U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  Analysis 
Center 

TRADOC 

U.S.  Army  Training  and  Doctrine  Command 

V&V 

verification  and  validation 

VSTARS 

Virtual  Surveillance  Target  Attack  Radar  System 

W&A 

verification,  validation  and  accreditation 

WSMR 

White  Sands  Missile  Range 
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Appendix  A 
Northrop  Grumman 

Verification  and  Validation  Plan  for  Phase  2 
of  the 

Virtual  Surveillance  Target  Attack  Radar  System  (VSTARS) 
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1  SCOPE 

This  document  provides  Verification  and  Validation  (V&V)  planning  information  for  Phase  II  of 
the  Virtual  Surveillance  Target  Attack  Radar  System  (VSTARS)  Joint  Advanced  Distributed 
Simulation  (JADS)  program.  The  VSTARS  V&V  Plan  is  submitted  in  response  to  Contract  Data 
Requirement  List  (CDRL)  item  A004  under  the  JADS  Program  Contract  No.  F30602-96-C-0281. 
Content  and  format  are  as  specified  by  the  contractor  and  in  accordance  with  the  Statement  of 
Work  (SOW)  paragraph  4.5 . 

VSTARS  Phase  II  V&V  will  be  conducted  by  Northrop  Grumman  test  engineers  at  the  Northrop 
Grumman  test  facility  located  at  Melbourne,  FL.  Verification  pass/fail  criteria  will  be 
accomplished  using  both  real-time  visual  data  demonstrations  and  post-V&V  data  reductions. 

1.1  Purpose 

The  purpose  of  this  V&V  plan  is  to  define  the  processes  to  be  used  to  meet  JADS  Phase  II 
objectives. 

1.2  Verification  Requirements 

This  plan  covers  the  requirements  of  document  JADS-RPT-002  Engineering  Design  Report  for 
the  Radar  Processor  Simulation  for  the  Joint  Surveillance  Target  Attack  Radar  System  dated  May 
1996. 

1.3  VSTARS  Program  Schedule 

V&V  for  Phase  II  will  be  executed  in  accordance  with  the  Phase  II  V&V  master  schedule. 

2.  APPLICABLE  DOCUMENTS 


2.1  Documents 

Document  C99SR077 
Sept  24  1997 
PR  No.  A-6-1763 
July  1996 

JADS-RPT-001  for 
March  1996 
JADS-RPT-002 
May  1996 


Preliminary  Performance  Assessment  Test  Plan  For  Phase  I  of  the 
VSTARS 

Statement  of  Work  for  Joint  Advanced  Distributed  Simulation  of 
JSTARS. 

Architectural  Design  Report  for  the  Radar  Processor  Simulation  the 
Joint  Surveillance  Target  Attack  Radar  System 
Engineering  Design  Report  for  the  Radar  Processor  Simulation  for  the 
Joint  Surveillance  Target  Attack  Radar  System  (EDR) 
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3.  VSTARS  PHASE  II  VERIFICATION  AND  VALIDATION  PROGRAM 

3.1  VSTARS 

VSTARS  consists  of  the  following  subsystems; 

1 .  Radar  Processor  Simulation  and  Integrator  (RPSI) 

•  Moving  Target  Indicator  Radar  Simulation  (MTISIM) 

•  Synthetic  Aperture  Radar  Simulation  (Advanced  Radar  Imaging  Emulation  System 
(ARIES))  (SARSIM) 

•  Fixed  Target  Indicator  Radar  Simulation  (FTISIM) 

•  Air  Network  Interface  Unit  (ANIU) 

2.  Advanced  Radar  Imaging  Emulation  (ARIES) 

3.  Distributed  Interactive  Simulation  Network  Interface  Unit  (DISNIU) 

•  Ground  Network  Interface  Unit 

4.  Surveillance  and  Control  Data  Link  Simulation  (SCDLSIM) 

The  following  laboratory  software  tools  are  used  in  support  of  VSTARS: 

•  Programmable  Signal  Processor  Simulation  (PSPSIM)  For  Lab  Use  Only. 

•  Navigation  Simulation  (NAVSIM).  For  Lab  Use  Only. 

3.1.1  Distributed  Interactive  Simulation  Network  Interface  Unit  (DISNIU)  Receiving 

The  ground  network  interface  unit  (GNIU),  receives  and  processes  Entity  State  Protocol  Data 
Units  (ESPDU)  from  the  ETE  DIS  network  via  a  T1  communications  circuit.  The  GNIU  reduces 
the  ESPDU  data  to  a  stripped  data  packet,  normally  referred  to  as  a  VSTARS  data  packet,  for 
transmission  to  the  air  portion  of  the  DISNIU,  known  as  the  ANIU.  The  minimum  formats  and 
contents  of  the  VSTARS  data  packets  transmitted  by  the  GNIU  and  ANIU  are  shown  in  Table  3- 
1  and  Table  3-2. 
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Table  3-1  Uplink  Entity  State  PDU  for  JADS  RPSI 


FIELD  DATA 

FORMAT 

BITS  IN 

FIELD 

INFORMATION 

Time  Stamp 

Unsigned 

Integer 

32 

JANUS  Game  time 

Local  Target  ID 

Unsigned 

Short 

16 

Local  Target  ID  No. 

TCS  X  Cell 

Unsigned 

Short 

16 

4K  cell  and  16m  cell  in  Y 
axis 

TCS  Y  Cell 

Unsigned  short 

16 

4K  cell  and  16  m  cell  in  X 
axis 

TCS  Z  Cell 

Unsigned 

Short 

16 

(16383)m  lsb=0.5m 

Velocity  X 

Short 

16 

(200)m/s  lsb=6.1035mm/sec 

mmssmm 

Short 

16 

(200)m/s  lsb=6.1035mm/sec 

Velocity  Z 

Short 

16 

(200)m/s  lsb=6.1035mm/sec 

Entity  Category 

char 

8 

enumeration 

Entity  Sub 

Category 

char 

8 

enumeration 

Entity  Specific 

char 

8 

enumeration 

Appearance 

char 

8 

8  bit  extraction  from  32  bits 

Orientation  Angle 

short 

16 

(180)deg.  extraction  from  32 
bits 

TOTAL  BITS 

192 

Table  3-2  Downlink  Entity  State  PDU  for  JADS  RPSI 


FIELD 

DATA 

FORMAT 

BITS  IN 
FIELD 

Time  Stamp 

Unsigned 

Integer 

32 

TCS  Location 
X 

Float 

32 

TCS  Location 
Y 

Float 

32 

TCS  Location 
Z 

Float 

32 

TCS  Velocity 
X 

Float 

32 

TCS  Velocity 
Y 

Float 

32 
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TCS  Velocity 

Float 

32 

Z 

TBD 

Integer 

32 

TOTAL  BITS 

256 

The  DISNIU  will  receive  and  process  Entity  State  Protocol  Data  Units  (ESPDU)  from  the  ETE 
DIS  network  at  a  rate  greater  that  the  maximum  rate  capable  of  being  transmitted  over  a  T1 
communications  circuit.  This  is  determined  by  replay  of  a  DISNIU  scenario  at  3  times  normal 
speed.  The  DISNIU  will  reduce  the  ESPDU  data  to  a  stripped  data  packet  for  transmission  to  the 
RPSI.  It  will  determine  the  minimum  formats  and  contents  of  these  data  packets  transmitted  by 
the  DISNIU  that  are  necessary  for  the  operation  of  the  RPSI. 

3.1.2  Distributed  Interactive  Simulation  Network  Interface  Unit  (DISNIU)  Transmitting 

The  GNIU  will  format  and  transmit  ESPDU  onto  the  ETE  DIS  network  denoting  the  existence 
and  virtual  location  of  VSTARS.  The  format  of  the  ESPDU  will  conform  to  IEEE  1278  DIS 
2.0.4  standards.  Pre-V&V  Procedures 

The  following  need  to  be  verified  prior  to  any  V&V  activity: 

1 .  DEC  Alpha  600’s  are  powered  on  and  operational. 

2.  Silicon  Graphics  Incorporated  (SGI)  PDU  logger  is  powered  on  and  operational. 

3.  Current  VSTARS  software  is  loaded  on  the  Alpha  computersone  of  the  JADS 
workstations. 

4.  Current  ARIES  software  is  loaded  on  the  Alpha  JADS02  workstation. 

5.  The  workstations  are  linked  by  a  JADS  LAN. 

Also,  prior  to  formal  execution  of  any  Phase  II  V&V  procedure,  test  engineers  will  ensure  that 
any  applicable  extraneous  log  files,  data  recordings,  etc.  are  removed  from  the  system.  Unless  a 
particular  procedure  indicates  otherwise,  the  steps  listed  in  Appendix  A  will  be  followed  to  start 
VSTARS.  The  Graphics  Display  (GD)  will  have  pre-determined  Areas  of  Interest  (AOI)  showing 
live  only,  virtual  only,  and  mixed  data. 
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3.2  Equipment  Configuration 

The  formal  V&V  configuration  block  diagram  is  depicted  in  Figure  3-1. 


TADSOl  Alpha  600  JAPSQ2  AlphaJSQQ 


Figure  3-1  -  VS  TARS  Phase  II  Configuration 

3.3  Test  Tools 

Software  tools  will  be  used  during  V&V  execution  for  both  real  time  and  post  procedure  analysis. 

3.3.1  MSGMON 

MSGMON  (Message  Monitor)  is  a  Joint  STARS  software  tool  that  copies  messages  generated  by 
Joint  STARS  into  a  database  that  allows  a  user  to  view  the  message  sequence  as  well  as  the  ten 
most  recent  messages  real  time. 

3.3.2  J ADS/VST ARS  Data  Reduction  Program  (DRP) 

JADS/VSTARS  DRP  will  be  used  for  analysis  of  VSTARS  specific  data.  The  operator  is  able  to 
make  recordings  of  both  processed  and  unprocessed  GNIU  and  ANIU  data.  The  target 
coordinates  output  will  be  in  Topocentric  Coordinate  System  (TCS),  Latitude/Longitude,  and 
Time-Space  Position  Information  (TSPI)  format.  The  data  will  be  used  to  demonstrate  ground 
truth,  coordinate  conversion,  and  dead  reckoning  calculations.  In  addition,  in  conjunction  with 
target  reports,  the  data  can  be  used  by  the  contractor  for  Probability  of  Detection  and  Circular 
Error  Probability  calculation. 
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3.3.3  JADS  Toolbox 

The  JADS  Toolbox  is  a  JADS  JTF  utility  installed  on  the  Silicon  Graphics  INDY  machine  and  is 
used  to  perform  analysis  of  logged  ESPDU  files.  For  V&V,  this  tool  will  be  utilized  to  verify 
that  VSTARS  transmits  an  E-8C  ESPDU  over  the  network. 

3.4  Twelve  Target  Scenario 

JADS  JTF  will  provide  a  twelve  target  scenario  created  with  JANUS  for  use  during  Phase  II 
V&V.  Target  ground  truth  data  will  be  available  for  this  scenario  for  use  in  analysis  during  and 
following  the  V&V  activities,  when  log  files  are  generated. 
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4.  V&V  Program  Activities 

This  section  of  the  Phase  II  V&V  plan  provides  descriptions  of  V&V  objectives  and  outlines  the 
procedures  which  will  be  used  to  verify  those  objectives.  Appendices  B-G  (Test  Data  Sheets) 
contain  the  actual  procedure  steps  that  are  described  below. 

4.1  VSTARS  MTI  Verification 

EDR:  (3.2.3  [23],  3.2.1.1.1  [6,7],  3.2.2.1.3  [26],  3.2.2.1.4  [27],  3.2.2.1.5  [28],  3.2.4.2  [45], 
3.2.2.2  [29],  3.2.2  [24],  3.2.4.2  [45],  3.2.4.3  [46],  3.2.2  [23], 3.2.2  [28])(5.3.1-a,  b,  e;  5.3.4-b,  c, 
d;  5.3.5-b,  c,  d;  5.3.7-a,  b,  c;  5.3.8-a) 

Verify  that  VSTARS  receives  and  integrates  virtual  data  from  the  JADS  JTF  test  environment. 
Verify  that  VSTARS  operates  in  three  modes:  live  only,  mixed  live  and  virtual,  and  virtual  only 
using  standard  Joint  STARS  MTI  message  format.  Verify  that  the  PSP  Simulation  receives  and 
processes  parameter  data.  Verify  that  MTI  Radar  Simulation  receives  target  reports  from  the 
RPSI  M&IS  and  performs  on  a  dwell  basis.  Verify  that  the  MTI  Radar  Simulation  has  minimal 
impact  upon  the  radar  timeline.  Verify  that  the  PSP  and  Navigation  Simulation  are  operational. 

4.1.1  Detailed  Description 

For  this  procedure,  the  V&V  Operator  will  first  start  VSTARS  without  DISNIU.  For 
demonstration  purposes,  virtual  targets  will  be  tagged  as  wheeled  targets  and  will  appear  magenta 
on  the  graphics  display  (GD),  while  live  targets  will  be  tagged  as  tracked  targets  and  will  appear 
amber  on  the  GD.  The  operator  will  then  start  MSGMON  on  the  JADS02  machine  and  set  up 
the  tool  to  first  display  MTI  messages  processed  on  GPC2  (RDP)  and  GPC3  (MTISIM).  Once  all 
tools  are  setup,  the  first  demonstration  will  show  that  VSTARS  can  have  live  data  only  (noise  in 
the  laboratory  environment)  displayed.  Looking  at  both  MSGMON  and  virtual  Jammed  Azimuth 
data  (which  will  visually  display  the  radar  dwells),  the  operator  will  demonstrate  that  the  system 
performs  on  dwell  basis.  Next,  DISNIU  playback  will  be  activated  to  load  virtual  targets  into  the 
system  and  live  targets  will  be  turned  off.  VSTARS  will  have  only  a  virtual  target  area  displayed 
and  MSGMON  again  will  be  used  to  compare  MTI  messages  .  Finally,  live  targets  will  be 
activated  again  to  observe  VSTARS  display  a  mixed  area  of  target  data.  Throughout  the 
procedure,  the  Approved  RSR  List  TD  will  be  observed  to  show  that  the  Ground  Reference 
Radar  Coverage  Area  (GRCA)  does  not  exceed  Joint  STARS  spec  timeline  requirements.  Final 
steps  will  have  MSGMON  display  MTI  Parameter  Messages  to  demonstrate  that  VSTARS 
receives  and  processes  PSP  parameter  data.  By  accomplishing  all  of  the  above,  PSP  and  N 
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4.2  ARIES  SAR  Validation 

EDR:  (3.2.3  [41,  42],  3.2.4.2  [45],  3.2.4.3  [46],  3.2.2  [23])Verification  Requirements:  (5.3.1- 
c,  e;  5.3.4-e,  f;  5.3.6-b,  c;  5.3.7-a,  b,  c;  5.3.8-a) 

Verify  that  VSTARS  displays  live  (noise  in  laboratory  version)  SARs  in  live  AOIs,  and  virtual 
SARs  in  mixed  and  virtual  areas  using  standard  Joint  STARS  SAR  message  format.  Verify  that 
of  PSP  Simulation  and  Navigation  Simulation  are  operational. 

4.2.1  Detailed  Description 

SAR  requests  will  be  initiated  in  both  live  and  virtual  areas  and  will  be  displayed  on  the  Graphics 
Display  (GD).  SAR  images  will  be  visually  inspected.  MSGMON  will  be  utilized  to  observe 
Joint  STARS  SAR  messages  real-time  for  both  virtual  and  live  areas.  Accomplishing  all  of  the 
above  demonstrates  that  PSP  and  Navigation  Simulation  are  operational. 

The  CPU  monitoring/reporting  function  provides  the  ability  to  report  CPU  utilization  for  each 
CPU  in  1 -second  intervals  via  an  output  data  file  and  has  the  capability  to  execute  from  2  to  1800 
seconds. 

4.3  VSTARS  Operator  Interference  Verification 
EDR:  (3.1.1  [3]) 

Verify  that  in  all  modes  of  operation,  VSTARS  will  permit  all  of  the  installed  operator 
workstation  software  to  function  without  abnormal  fault  messages  occurring.  Abnormal  fault 
messages  are  defined  as  those  caused  specifically  by  the  use  of  VSTARS. 

4.3.1  Detailed  Description 

Various  Joint  STARS  functions  will  be  presented  to  show  that  abnormal  fault  messages  do  not 
occur  while  VSTARS  is  operating.  The  following  functions  will  be  demonstrated: 

•  The  route  function 

•  The  tracker 

•  Order  of  battle 

•  Radar  functions 

If  while  executing  this  procedure  any  function  does  not  operate  as  expected,  it  will  be 
documented. 
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4.3.2  ANIU  and  GNIU  Verification 

EDR:  (3.2.1.3.4  [20],  3.2.1.3.3  [17],  3.2.1.3.3  [18],  3.2.1.3.6  [22],  3.2.1.3  [12],  3.2.1.3.5  [21], 

3.2.4.2.[46]) 

This  procedure  will  accomplish  the  following  requirements  in  three  test  cases: 

•  Test  Case  #1  -  Verily  that  the  GNIU  receives  and  processes  DIS  2.0.4  Entity  State 
Protocol  Data  Units  (ESPDU)  from  the  ETE  Test  DIS  network  at  a  rate  of  100 
ESPDUs/second.  Demonstrate  that  the  GNIU  can  process  ESPDUs  at  a  rate  greater  than 
350  ESPDU/second.  Verify  that  the  VSTARS  data  packet  is  than  192  bits. 

•  Test  Case  #2  -  Verify  that  the  ANIU  provides  the  necessary  data  required  by  the  GNIU, 
and  that  the  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity  state  of  the  E- 
8C  based  on  data  received  from  the  ANIU. 

•  Test  Case  #3  -  Verify  that  the  GNIU  performs  a  coordinate  transformation  upon  entities 
selected  for  transmittal  to  the  ANIU  and  prepares  a  VSTARS  data  packet,  containing  all 
entity  data  required  by  the  RPSI,  for  transmittal  to  the  ANIU.  In  addition,  verify  that  the 
ANIU  stores  entity  data  and  conducts  dead  reckoning  upon  moving  targets  at  a  minimum 
rate  of  1/second. 

4.3.3  Detailed  Description 

•  Test  Case  #1  -  The  JADS/VSTARS  DRP  will  be  used  to  replay  ESPDUs  at  an  accelerated 
playback  rate.  An  analysis  of  the  playback  will  be  done,  which  will  show  a  calculation  of 
the  number  of  PDUs  that  were  processed  during  the  playback.  The  ESPDU  DIS  logger 
will  be  used  to  replay  ESPDUs  three  times  normal  speed.  The  first  replay  is  accomplished 
with  DISNIU  recording  turned  off.  After  the  first  replay,  perform  a  second  with  DISNIU 
recording  turned  on. 

•  Test  Case  #2  -  The  SGI  will  be  set  up  for  logging  a  DIS  file.  On  VSTARS,  the  E-8C 
ESPDU  transmittal  function  will  be  activated  via  the  JADS/VSTARS  DRP .  The  data  will 
be  logged  for  approximately  five  minutes.  The  JADS  Toolbox  will  be  used  to  look  at  the 
parameters  of  the  logged  aircraft  ESPDU. 

•  Test  Case  #3  -  The  Twelve  Target  Scenario  will  be  started  with  DIS  Logger  running. 
Then  the  JADS/VSTARS  DRP  will  be  used  to  extract  TCS  coordinates  from  the  GNIU 
input  data  and  compare  them  to  ANIU  output  data.  Dead  reckoned  targets  will  be 
analyzed  to  verify  they  are  updated  once  per  second  and  that  the  dead  reckoned 
calculations  have  the  appropriate  distance  and  direction  based  on  the  input  target 
movements. 
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4.3.4  Turing  Test 
EDR:  (3.2.2  [23]) 

The  Turing  test  will  be  performed  by  Northrop  Grumman  and  the  Joint  STARS  Joint  Test  Force 
with  JADS  ETE  V&V  team  oversight.  The  purpose  of  the  Turing  test  is  to  ensure  that  there  are 
no  major  distinguishable  differences  to  Joint  STARS  operators  between  VSTARS  and  the  actual 
Joint  STARS  radar  picture.  The  following  areas  will  be  validated: 

•  Operational  behavior  characteristics  of  the  virtual  targets  shall  not  differ  noticeably  from  the 
operational  characteristics  of  real  targets  and  have  minimal  impact  upon  the  radar  timeline. 

•  Validate  that  ARIES  visually  matches  the  fidelity  of  Joint  STARS  SAR  images,  and  that 
ARIES  has  minimal  impact  upon  the  radar  timeline. 

4.3.5  Detailed  Description 

Using  a  JANUS  Vignette,  Joint  STARS  JTF  tactics  will  develop  a  tasking  order.  Prior  to  the 
Turing  test,  Northrop  Grumman  will  brief  test  participants  on  the  scenario.  There  will  be  two 
workstations  in  the  OCTL  and  one  in  the  JADS  laboratory.  The  operator  in  the  JADS  laboratory 
will  be  the  Sensor  Management  Officer  (SMO).  The  operators  will  be  told  that  they  are 
evaluating  the  performance  of  VSTARS.  After  the  test,  a  testing  psychologist  will  interview 
participants  and  evaluate  their  responses.  The  responses  will  be  used  to  validate  that  ARIES  had 
minimal  impact  on  the  radar  timeline. 

5.  Reports 

A  test  report  will  be  submitted  to  JADS  JTF  at  the  conclusion  of  the  Phase  II  V&V  testing. 
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APPENDIX  A 

Preliminary  Procedures  for  JADs  Formal  Test 


DOCUMENT  NO:  C99SR090 
APPENDIX  A 
DATE:  4  June  1998 

Procedures  for  performing  JADS  Verification 
1.1  Pre-Test  Procedures 


Step  # 

Action 

Event 

■ 

Verify  the  Alpla  and  SGI  are  powered  up  and 
initialized. 

2. 

Connect  all  workstations  and  SGI  to  the  T1  line 
and  log  into  logbook. 

Enables  connection  to  the  SGI  for  DISPDU 
playback. 

3. 

Logon  to  ATWS  and  enter  PERM  Number. 

Joint  STARS  start-up  screen  appears.  After  a  few 
minutes,  Joint  STARS  windows  initialize. 

4. 

Assign  console  Tech  Control. 

Technician  Push-button  menus  are  made  available, 

5. 

Open  the  OAC  STAT  RCFG  TD  under  STAT 
RCFG  Push-button  Menu. 

A  window  showing  the  status  of  the  SMCs  and 
GPCs. 

6. 

When  GPC  1,  2,  and  3  go  to  operate,  access  the 
PROC  PRIV  ALLOC  TD  and  select  MSU 
radio  button. 

Enables  Mission  Support  Utilities  functions. 

7. 

In  DECterm  >  Type 

set  def  dkaO:[secret_radar_dir]  then  type  dir 

Sets  the  default  directory. 

8. 

Delete  all  SARF  ,  HIST,  and  THIS  files. 

This  will  free  up  disk  space  for  recording  and  new 
history  files. 

To  Brir 

ig  Up  NAVSIM 

9. 

Use  the  pull  down  menu  to  bring  up  a 

DECterm  window. 

DECterm  window  displayed. 

10. 

In  DECterm  >  Type  rtmission  jads02.‘ 

Rtmission  window  appears  showing  logon  prompt. 

11. 

In  rtmission  >  Logon  to  MISSION 

Prompt  for  password  and  perm  number  displayed. 

'  *  Type  in  the  number  of  the  JADS  node  you  are  working  on. 
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Step  # 

Action 

Event 

12. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DEC$Terminal_NSE.dat 

Displays  files  selection  options  for  saved  window 
names. 

13. 

In  NSE  >  Type 

@[nserdi.com]nse_run_nse 

Initializes  NSE  (the  nav  sim)  and  the  NSE  menu 
appears  in  the  window  after  “ALTUNT”. 

14. 

In  DECterm  >  Type  rtmission  jadsOl.2 

Rtmission  1  window  appears  showing  logon 
prompt. 

■ 

In  rtmission  >  Logon  to  MISSION 

Prompt  for  password  and  perm  number  displayed. 

■ 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DECSTerminaLPJNAV.dat 

Displays  files  selection  options  for  saved  window 
names. 

17. 

In  PJNAV>  type 

@j  star  s_build„root :  [com]  run_j  ads_nav 

Runs  JADS  Nav  sim  and  attaches  itself  to  the  NSE 
window. 

18. 

In  NSE  >  Use  the  cursor  to  select 
“configuration”  and  press  return. 

Displays  NSERDI  configuration  menu. 

19. 

In  NSE  >  Use  the  cursor  to  select  “load  cfg  file” 
and  press  return. 

Displays  load  configuration. 

20. 

In  NSE  >  Use  the  cursor  to  select  “select  cfg  file” 
and  press  return. 

Displays  list  of  available  files. 

21. 

In  NSE  >  Use  the  cursor  to  select  “jads_TJDT”3 
and  press  return. 

Displays  file  loaded  message. 

22. 

In  NSE  >  Use  the  cursor  to  select  “exit”  and 
press  return. 

NSE/RDI  configuration  widow  displayed. 

23. 

In  NSE  >  Use  the  cursor  to  select  “exit”  and 
press  return. 

Window  display  reverts  to  original  NSE/RDI 
version  3.5  window. 

24. 

In  NSE  >  Use  the  cursor  to  select  “start 
simulation”  and  press  return. 

Displays  simulation  control  window. 

2  *  Type  in  the  number  of  the  JADS  node  you  are  working  on. 

3  Select  the  correct  file  name  for  your  scenario. 
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Step  #  Action  Event 

25.  In  NSE  >  Use  the  cursor  to  select  “start”  and  NSE  processes  run. 

press  return. 

To  Bring  Up  PJJMON 

26.  In  DECterm,  type  rtmission  jadsOl.*  Rtmission  window  appears  showing  logon  prompt. 

27.  In  rtmission  >  Logon  to  MISSION3  Prompt  for  password  and  perm  number  displayed. 


28. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DECSTerminaLPJJMON.dat 

Displays  files  selection  options  for  saved  window 
names. 

29. 

If  your  login  does  not  automatically  set 
proc/priv=all,  type  set  proc/priv=all 

Give  you  privileges  needed  to  perform 
functions  in  Open  VMS.  (PSPSIM  will  not  stay 
on  if  you  have  not  done  this). 

30. 

In  PJJMON  >  Type  set  def  runtime_dir 

Set  default  directory  to  runtime_dir. 

31. 

In  PJJMON  >  Type  run  pjjmon 

Displays  JADS  Control  window. 

32. 

In  PJJMON  >  Type  1 

Displays  JADS  Process  Control  configuration. 

33. 

In  PJJMON  >  Type  1 

MTISIM  selected  for  configuration  and  asks 
for  an  “enter  option” 

34. 

In  PJJMON  >  Type  L 

Loads  MTISIM. 

35. 

In  PJJMON  >  Type  3 

PSPSIM  selected  for  configuration. 

36. 

In  PJJMON  >  Type  L 

Loads  PSPSIM. 

37. 

In  PJJMON  >  Type  R 

Applies  modifications  to  JADS  Process 
Control.  Do  not  exit  before  you  reconfigure. 
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Step  # 

Action 

Event 

38. 

In  PJJMON  >  Type  X 

Return  to  the  JADS  Control  Window. 

39. 

In  PJJMON  >  Type  2 

The  MTI  Simulation  Control  Parameters 
Window  selected. 

40. 

Ensure  the  following  default  values  are  displayed: 

1  -  Turn  off  PD  (Probability  of  Detection) 

2  -  Turn  off  PFA  (Probability  of  False  Alarms) 

3  -  Turn  off  CEP  (Circular  Error  of  Probability) 

4  -  Turn  off  CEP  of  X-RNG  and  D-RNG  Bias 

5  -  Turn  off  Terrain  Screening 

6  -  Set  (Live=tracked)  and  (Virtual=wheeled) 

7  -  Load  DIS  target  ID  into  MC44  report 

8  -  Display  Mixed  Mode  in  Same  Area 

9-  Display  Dummy  Targets 

10  -  Minimum  Detectable  Velocity  (M/S) 

1 1  -  Minimum  CEP  Cross  Range  Error 

12  -  Minimum  CEP  Down  Range  Error 

13  -  Minimum  PFA 

14  -  Minimum  PD  Cross  Loss  (dB) 

15  -  Monitoring  Virtual  Data  ID  (-1  for  all) 

X  -  Exit 

F 

F 

F 

F 

F 

F 

F 

Set  to  0  for  scenario 

-1 

41. 

In  PJJMON  >  Type  X  and  iconify  window. 

Exit  back  to  the  JADS  Control  window. 

To  Bring  Up  PPKOCO 

42. 

In.  DECterm ,  type  rtmission  jadsOl.* 

Rtmission  window  appears  showing  logon  prompt. 
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Step  # 

Action 

Event 

Q 

In  rtmission  >  Logon  to  MISSION2 

Prompt  for  password  and  perm  number  displayed. 

■ 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DECSTerminaLPKXOCO.dat 

Displays  files  selection  options  for  saved  window 
names. 

45. 

In  PKXOCO  >  Type  OCO_TASK 

Displays  PKXOCO  Selection  window. 

46. 

In  PKXOCO  >  Hit  return  to  select  default  of  5. 

Opens  System  Summary  window. 

47. 

In  PKXOCO  >  Type  2  and  press  return. 

System  State  is  now  in  operate. 

48. 

In  PKXOCO  >  Hit  return 

Displays  System  Monitor  window. 

To  Bring  Up  ARIES  (SARSIM) 

49. 

In  DECterm,  type  rtmission  jads02  * 

Rtmission  window  appears  showing  logon  prompt. 

50. 

In  rtmission  >  Logon  to  ARIES  if  SARSIM  is 
the  only  function  running  on  the  ATWS. 

Logon  to  ARIES1  if  Joint  STARS  and  JADS 
processes  are  running  on  the  same  machine  as 
SARSIM. 

Prompt  for  password  and  perm  number  displayed. 
After  perm  number  is  input,  SARSIM 
automatically  starts.  If  the  system  comes  down, 
you  logged  on  to  the  wrong  ARIES  account  and 
must  do  a  JSMENU  5  to  restart  Joint  STARS 

51. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DEC$Terminal_ARIES.dat 

Displays  files  selection  options  for  saved  window 
names. 

52. 

In  ARIES  >  At  prompt,  “Do  you  want  to  run 
SARSIM  in  stand  alone  mode  (y/n)”  press 

return. 

Yes  is  selected  as  the  default  to  allow  stand  alone 
operations. 

53. 

In  ARIES  >  At  prompt,  “Do  you  want  to  change 
the  mission  center  (y/n)  press  return. 

The  default  of  no  change  to  the  mission  center  is 
selected. 

54. 

SARSIM  automatically  initializes. 

“Initialization  successful”  is  displayed  in  the 
window. 
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Step  # 

Action 

Event 

55. 

Delete  all  RSRs  left  over  on  the  GD  from 
previous  sessions. 

No  RSRs  are  approved. 

56. 

Deselect  all  MFPs  for  show  except  the  required 

(Do  not  delete,  just  do  not  show) 

Deselected  flight  plans  do  not  appear  on  GD.  They 
remain  in  the  data  base. 

The  following  steps  bring  up  the  DISNETWORK  and  the  Silicon  Graphics  Machine  (SGI),  do  not  bring 
them  up  unless  the  procedure  refers  you  back  to  this  appendix. 


To  Bring  Up  DISNIU 

57. 

Use  the  pull  down  menu  to  bring  up  a  DECterm 
window. 

DECterm  window  displayed. 

58. 

In  DECterm  >  type  rtmission  JADSOx.  (Insert 
JADS  workstation  number  for  x) 

DECterm  window  appears  showing  logon  prompt. 

■ 

In  DECterm  >  Logon  to  MISSION3 

Prompt  for  password  and  perm  number  displayed. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DEC$Terminal_DISMON.dat 

Displays  files  selection  options  for  saved  window 
names. 

61. 

In  another  DECterm  >  ,  type  rtmission 

JADSOx.  (Insert  JADS  workstation  number  for 
X) 

DECterm  window  appears  showing  logon  prompt. 

62. 

In  DECterm  >  Logon  to  MISSION3 

Prompt  for  password  and  perm  number  displayed. 

63. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DEC$Terminal_DISNIU.dat 

Displays  files  selection  options  for  saved  window 
names. 

64. 

In  DISNIU >  type  @user$disk:[util]start_disniu 
JADSOx  966  (or  correct  configuration) 

B.  Spalding  login  file  executes  to  set  up  symbols 
and  logicals.  Sets  up  network  environment  and 
enables  the  reading  of  PDUs. 

65. 

In  DISMON  >  type 

@user$disk:  [util]  start_disniu_monitor. 

B.  Spalding  login  file  executes  to  set  up  symbols 
and  logicals.  Brings  up  the  DISNIU  monitor. 
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66. 

Use  the  pull  down  menu  to  bring  up  a  DECterm 
window. 

DECterm  window  displayed. 

67. 

In  the  new  DECterm  window>type 

telnet  199.26.42.100. 

Telnet  to  SGI. 

68. 

At  login:  type  root  (in  lower  case) 

Logon  to  SGI  root  account 

69. 

At  password :  type  the  correct  password 

(lowercase) 

Enables  logon  to  root  account  and  displays 
“Grumman  #1”  prompt. 

70. 

Go  to  the  options  feature  and  select  Restore 
Named  Options  in  the  pull  down  menu.  Select 

DECSTerminaLSGI.dat 

Displays  files  selection  options  for  saved  window 
names. 

71. 

In  SGI  >  at  grumman  1#  prompt,  type 

cd  /usr/local/bin 

Brings  up  JADS  Logger. 

72. 

In  SGI  >  type  Is 

Directory  is  displayed. 

73. 

In  SGI  >  type  Is  /disk2/v_v_logfiles 

List  of  directories  under  either  v_v_logfiles  are 
displayed. 

74. 

In  SGI  >  type 

jads_player*  3000  1  /disk2/  v_y_logfiles 
/(filename) 

Selected  pre-recorded  file  is  played  back  on  the 
SGI  and  transmitted  to  JADS.Opens  selected 
JADS  Logger  file. 
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VSTARS  MTI  Verification  -  Verify  that  VSTARS  receives  and  integrates  virtual  data  from 
the  JADS  JTF  test  environment.  In  addition,  demonstrate  with  the  current  Joint  STARS 
software  build  that  VSTARS  operates  in  three  modes:  live  only,  mixed  live  and  virtual, 
and  virtual  only  using  standard  Joint  STARS  MTI  message  format.  Verify  that  the  PSP 
Simulation  receives  and  processes  parameter  data  and  MTI  Radar  Simulation  receives 
target  reports  from  the  RPSI  M&IS,  and  performs  on  a  dwell  basis.  Verify  that  the  MTI 
Radar  Simulation  has  minimal  impact  upon  the  radar  timeline.  Verify  the  functionality  of 

the  PSP  and  Navigation  Simulation. 


Step# 

Action 

Event 

Pass/Fail 

1. 

Start  VSTARS  according  to  Appendix  A.  Bring 
up  the  OCO_TASK  and  DISSIM  windows,  but 
do  not  start  the  processes.  SGI  will  be  brought 
up  later  in  this  procedure. 

Note:  ARIES  is  not  necessary  for  this  procedure. 

VSTARS  started  without 
OCO.TASK  and  DISSIM  running. 

2. 

Bring  up  the  APPV  RSR  TD: 

Place  mouse  pointer  over  symbol  on 
Graphics  Display  (GD)  and  press  the  left 
mouse  button. 

Scroll  down  to  Go  to  TD  F19  selection  and 
press  left  mouse  button 

In  the  Enter  TD  Number  field,  type  2  and  use 
mouse  pointer  to  select  enter. 

APPV  RSR  TD  is  displayed, 
showing  that  the  only  active  RSR  is 
the  GRCA  labeled  V_V;  revisit  rate 
is  visible  on  the  TD  as  well. 
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Step# 

Action 

Event 

Pass/Fail 

3. 

Remove  extraneous  flight  paths  from  GD. 

If  necessary,  select  PRI FCTN  button  on 

PDU. 

•  On  TECH  CNTRL  PDU,  select  MSN 

CMMN  SEL  button. 

•  Select  FLT  PLN  MGT  button 

•  Select  AUX  FLT  PLNG  button 

Select  FLT  PLN  List  button 

Deselect  the  S  button  on  all  flight  paths 
except  TJU102,  press  ENTER 

Select  the  PRI  FCTN  button. 

•  TECH  CNTRL  PDU  is 
displayed 

•  MSN  CMMN  SEL  menu 
displayed 

FLT  PLN  MGT  menu  displayed 

•  AUX  FLT  PLNG  menu  displays 
FLT  PLN  List  TD  displayed 

Only  flight  path  labeled  TJU 102 
is  displayed  on  the  GD. 

TECH  CNTRL  menu  displayed. 

-  V  •  •/  V  • 
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Step  # 

Action 

Event 

Pass/FaU 

4. 

Remove  extraneous  Order  of  Battle  Areas  from 
GD. 

On  PDU  select  MSN  CMMN  SEL  button. 

Select  PROC  OB  button 

Select  OB  AREA  List  button 

Deselect  the  S  all  button  and  ENTER. 

Select  the  S  button  for  Live_AOI  and 
Mix_AOI  areas,  and  ENTER. 

•  Close  the  OB  AREA  LIST  TD 

Select  the  PRI FCTN  button. 

MSN  CMMN  SEL  menu 
displayed 

PROC  OB  menu  displayed 

OB  AREA  List  TD  displayed. 

OB  AREA  on  GD  disappear. 

Live_AOI  and  Mix_AOI  areas 
are  displayed  within  the  GRCA. 

•  OB  AREA  LIST  TD  is  closed. 
TECH  CNTRL  menu  displayed. 

Note:  If  the  Mix_AOI  area  has  been  deleted, 
create  new  area  at  the  following  X,Y,Z 
(clockwise  order)  coordinates: 

75960X,  4945 6 Y,  -452Z 

87864X,  495 84 Y,  -588Z 

87992X,  35888Y,  -480Z 

75704X,  3 5760 Y,  -325Z 

Note:  If  the  Live_AOI  area  has  been  deleted, 
create  new  area  at  the  following  X,Y,Z 
(clockwise  order)  coordinates: 

113976X,  12080Y,  -818Z 

126264X,  11824Y,  -1075Z 

127544X, -464Y,  -1102Z 

114744X,  -208Y,  -798Z 
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Step  # 

Action 

Event 

Pass/Fail 

5. 

Set  graphic  features  on  GD  for  all  scales. 

Press  right  mouse  button  over  the  GD 

Scroll  down  to  Graphic  Features 

Select/deselect  radio  buttons  for  the  graphic 
features  desired,  select  radio  button  for  ALL 
SCALES,  and  then  select  ENTER. 

The  following  graphic  features  will 
have  their  radio  button  active: 

Primary  Road 

Secondary  Road 

City/Town 

Tree/Desert 

River/Lake 

Political  Boundaries 

Sv..- 

6. 

Center  the  GRCA  on  the  GD  and  set  scale  to 
128km 

Place  mouse  pointer  in  center  of  GRCA 

Press  right  mouse  button  and  select  scales. 

Scroll  down  to  128km  and  press  left  mouse 
button. 

GRCA  fills  GD. 

7. 

Log  on  to  the  JADS02  machine  using  the 
MISSION  account. 

Enter  the  appropriate  password  and  perm 
number 

JADS02  is  logged  on  without  Joint 
STARS  software  running. 

8. 

On  JADS02,  bring  up  a  DECterm  window  and 
set  host  to  JADS01 .  Log  on  using  the 

MISSION2  account. 

DECterm  window  is  brought  up  and 
logged  onto  the  JADS01  RDP. 

9. 

On  JADS02,  bring  up  a  second  DECterm 
window  and  set  host  to  JADS01 .  Log  on  using 
the  MISSION3  account. 

DECterm  window  is  brought  up  and 
logged  onto  the  JADS01  SPR. 
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Step  # 

Action 

Event 

Pass/Fail 

10. 

On  the  first  DECterm  window,  open  the  Options 
feature  and  select  Restore  Named  Options  in  the 
pull  down  menu. 

select  user$disk:  [000000]  then  FILTER. 

select 

DECW$Terminal_Msgmon_RDP.dat 

select  OK 

The  DECterm  window  is  resized  and 
named  MSGMONRDP. 

L  ’H  ,  • 

11. 

On  the  second  DECterm  window,  open  the 

Options  feature  and  select  Restore  Named 

Options  in  the  pull  down  menu. 

select  userSdisk:  [000000]  then  FILTER. 

select 

DECW$Terminal_Msgmon_SPR.dat 

select  OK 

The  DECterm  window  is  resized  and 
named  MSGMON_SPR. 

12. 

For  both  DECterm  windows,  start  MSGMON: 

type  JSMENU,  enter 
type  16,  enter 
type  2,  enter 
type  3,  enter 

Message  Monitor  Program  V  1.0  is 
started  for  both  the  RDP  and  SPR 
GPC’s. 

a.5/  • 

A -24 


DOCUMENT  NO:  C99SR090 
DATE:  4  June  1998 


Step  # 

Action 

Event 

Pass/Fail 

13. 

In  the  MTISIM  Control  Parameters  menu 
( PJJMON  window  on  JADS01  console),  verify 
the  following  parameters  are  set  to  the  indicated 
values: 

1 .  T urn  off  PD  (Probability  of  Detection) 

T 

MTISIM  parameters  are  set  to 
display  clean  virtual  targets,  with 
virtual  targets  appearing  on  the 
screen  in  magenta,  while  live  targets 
will  appear  amber. 

«Vv-: A;;.; 

2. 

Turn  off  PFA  (Probability  of  False  Alarms) 

T 

3. 

Turn  off  CEP  (Circular  Error  Probability) 

T 

i. 

4. 

Turn  off  CEP  Center  of  X-RNG  and  D-RNG 
bias 

Six',  V 

T 

5. 

Turn  off  terrain  screening 

T 

6. 

Set  (Live=Tracked)  and  (Virtual^ Wheeled) 

T 

7. 

Load  DIS  Target  ID  into  MC44  report 

T 

8. 

Display  mixed  mode  in  same  area 

T 

9. 

Display  dummy  targets 

10. 

F 

Minimum  detectable  velocity 

0.0 
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.  Step  # 

Action 

Event 

Pass/Fail 

14. 

Exit  the  MTISIM  Parameters  menu  and  bring  up 
the  PSP  Parameters  menu. 

•  In  PJJMON,  type  3. 

In  PSP  Control  Parameters  menu,  type  8  then 
press  enter. 

Type  x  and  enter. 

Iconize  the  window 

PSP  load  set  to  90%,  making  it 
easier  to  see  live  targets. 

%  ■ 

15. 

In  PKXOCO  window  start  OCO_TASK. 

type  OCO_TASK,  and  enter. 

The  PKXOCO  Selection  window  is 
displayed. 

hi;  '  ;  :7 

16. 

In  the  PKXOCO  Selection  window,  hit  enter  to 
select  default  of  5. 

System  Summary  window  is 
displayed. 

k'  '  'i_  ' 

17. 

In  System  Summary  window,  type  2  and  enter. 

System  state  goes  from  standby  to 
operate;  system  alert  “RDR  IN 
OPERATE”  is  displayed. 

"  ■  v’ ‘ 

18. 

In  System  Summary  window,  hit  enter. 

Place  window  away  from  GD. 

System  Monitor  window  is 
displayed. 

19. 

Observe  on  the  GD  that  “live”  amber  targets 
appear  within  the  AOI’s;  observe  APPV  RSR 

TD  revisit  value. 

VSTARS  operates  in  live  target 
mode. 

APPV  RSR  TD  shows  revisit  value 
is  within  spec  requirements. 

Pass 

Fail 
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Pass/Fail 

20. 

Bring  up  the  PJJMON  window. 

Type  2  for  MTISIM  Control  Parameters 
window. 

Select  9  (Display  Dummy  Targets)  and  enter 

T. 

Type  x  and  enter. 

Iconize  the  window. 

Using  Jammer  Strobes,  the  radar 
swath  for  the  GRCA  with  its  dwells 
is  illustrated  on  the  screen. 

21. 

At  JADS02  console,  for  both  MSGMON 
windows: 

scroll  down  to  Select  Display  of  a  Message 
and  enter. 

scroll  down  to  page  1  (RDP  only) 
type  1,  and  enter. 

*  scroll  down  to  TARGET  JNDICATOR„RD 
and  enter. 

type  1  and  enter. 

Page  one  (1)  for  MC-44  MTI  Target 
Indicator  messages  for  RDP  (pre- 
RPSI  processing)  and  SPR  (RPSI 
processing)  are  displayed. 

by/'  •  - 

22. 

Observe  the  MHDR.  Source J^rocessJDD  in  the 
MSGMON_RDP  and  compare  with  the  process 
source  ID  in  the  MSGMON_SPR.  Observe 
job.rsrjype  and  job.refnum  values  on  both 
displays. 

Note:  Process  ID  numbers  can  be  verified  in  the 
gexp_exec_proc_ids.inc  file,  located  in  the 
following  directory: 

dka0:[cmsdsk.bld03_108b_secret.include_unclas 

sified] 

Source  ID  for  RDP  is  270  (this  value 
correlates  to  process  PK4RPT)  while 
source  ID  for  SPR  is  390  (this  value 
correlates  to  process  PJMTIS 
(MTISIM));  values  for  RSR  type 
and  RSR  reference  number  are 
identical,  demonstrating  that 

VSTARS  uses  the  same  MTI  Joint 
STARS  message  format. 

Pass 

Fail 
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23. 

At  JADS02  console,  for  both  MSGMON 
windows: 

press  enter 

type  3  and  enter. 

Page  three  (3)  for  MC-44  MTI 

Target  Indicator  messages  for  RDP 
(pre-RPSI  processing)  and  SPR 
(RPSI  processing)  are  displayed. 

24. 

Observe  on  GD  that  targets  fall  within  dwells; 
observe  on  both  MSGMON  windows  the 
dwell.tgt_cnt  field. 

MTI  is  reported  on  a  dwell  basis. 

MSGMONJRDP  target  per  dwell 
count  is  higher  than 

MSGMON_SPR  target  count;  RPSI 
M&SI  receives  outputs  from  RDP 
and  MTI  simulation  and  determines 
the  appropriate  distribution  of 
targets,  deleting  targets  that  fall 
outside  the  designated  live  areas. 

25. 

Bring  up  the  PJJMON  window. 

Type  3  for  PSP  Control  Parameters  window 
Type  11  and  enter,  then  type  0 

Type  x  to  return  to  the  main  menu 

Type  2  for  MTISIM  Control  Parameters 
window. 

Select  9  (Display  Dummy  Targets)  and  enter 
F. 

Type  x  to  return  to  main  menu. 

Iconize  the  window. 

PSP  generated  targets  are  turned  off; 
jammer  strobes  are  removed. 

26. 

Clear  the  GD  of  MTI 

Press  right  mouse  button  over  the  GD 

Scroll  down  to  Clear  MTI 

Select  Yes 

GD  is  cleared  of  all  targets. 

Pass/Fail 
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Pass/Fail 

27. 

In  the  DISMON  window,  start  the  DISNIU 
monitor. 

Type  @user$disk:[util]start_disniu_monitor 
and  enter. 

DISNIU  Monitor  is  activated. 

IT  '.J.S  ■' 

28. 

In  the  DISNIU  window,  start  the  DISSIM. 

Type  @user$disk:[util]start_disniu  JADS01 
966  and  enter. 

DISSIM  is  running. 

S;.\  ;  !  *7 

29. 

On  the  JADS01  console,  bring  up  a  new 

DECterm  window  for  SGI  playback. 

Outside  of  any  X-term  window,  press  mouse 
button. 

Under  Applications  window,  scroll  to 
DECterm/Screen  0  selection. 

A  new  DECterm  window  is 
displayed  on  the  JADS01  console. 

*  Jr;'" 

30. 

On  the  DECterm  window,  open  the  Options 
feature  and  select  Restore  Named  Options  in  the 
pull  down  menu. 

select  DECWSTerminaljSGLdat 

select  OK 

The  DECterm  window  is  renamed 
and  resized. 
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Pass/Fail 

31. 

Start  the  Twelve  Target  Scenario  on  the  SGI: 

in  the  SGI  window  type  telnet  199.26.42.100 
and  enter 

connects  to  the  SGI 

•feu, 

at  logon  type  root  and  the  correct 

logon  to  SGI  root  account 

L’"  hY 

password. 

set  directory  to  JADS  Logger 

at  grumman  1#  prompt,  type  cd 

/usr/local/bin  and  enter 

displays  directory 

type  Is  and  enter 

displays  directory  of  logfiles 

u  ■ .  • 

type  Is  /disk2/v_v_logfiles  and  enter 

starts  scenario 

type  jads_player*  3000  1 
/disk2/v_v_logfiles/(/i/enaffie)  and  enter 

32. 

Observe  on  GD  that  12  magenta  virtual  targets 

VSTARS  operates  in  live  target 

Pass 

appear  within  the  GRCA;  observe  APPV  RSR 

mode. 

Fail 

TD  revisit  value;  observe  on  both  MSGMON 

APPV  RSR  TD  shows  revisit  value 

windows  the  dwell.tgt_cnt  field. 

is  within  spec  requirements. 

MSGMON_RDP  target  per  dwell 

Pass 

count  is  zero  while  MSGMONJSPR 
target  count  fluctuates  between  0  and 
1;  RPSI  M&SI  receives  outputs 
from  RDP  and  MTI  simulation  and 
determines  the  appropriate 
distribution  of  targets  and  works  on 
a  per  dwell  basis. 

Fail 

33. 

Bring  up  the  PJJMON  window. 

Enables  a  PSP  load  of  50%. 

<v  ■■ 

Type  3  for  PSP  Parameters  window 

Select  5  and  enter 

Type  x  to  return  to  the  main  menu 
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34. 

Observe  on  the  GD  that  live  “amber”  targets  and 
virtual  “magenta”  targets  appear  together  in  the 
MIX_AOI  area;  observe  APPV  RSR  TD  revisit 
value;  observe  on  both  MSGMON  windows  the 
dwell.tgt_cnt  field. 

VSTARS  receives  virtual  and  live 
targets  and  integrates  it  on  the  GD. 

APPV  RSR  TD  shows  that  the  radar 
timeline  is  unaffected  by  VSTARS. 

MSGMON_RDP  target  per  count  is 
greater  than  MSGMON_SPR  target 
count;  VSTARS  receives  live  targets  1 
and  integrates  it  with  virtual  targets, 
then  distributes  the  targets  within  the 
appropriate  areas  (real,  virtual,  or 
mixed),  and  then  sends  the  composite 
report  to  the  radar  post  processor. 

35. 

On  JADS02,  in  both  MSGMON  windows  press 
enter  twice. 

The  Display  Message  selection  menu 
is  displayed  for  both 

MSGMON_RDP  and 
MSGMON_SPR. 

36. 

In  both  MSGMON  windows,  scroll  to 
MTI_PARAMETERS_MSG_XD  message  and 
press  enter. 

MC2 1  _MTI_P  ARAMETERS 
(a.k.a.  PSP  Parameters)  message  is 
displayed  for  both  the  RDP  and  SPR 
GPC’s. 

37. 

Compare  Source  ID  RDP  and  SPR  MSGMON. 

At  Test  Conductor’s  discretion,  message  on  both 
displays  can  be  paged  through  for  format 
comparisons. 

Process  source  ID  for  RDP  is  265 
(PK2MCP),  while  the  process  source 
ID  for  VSTARS  is  also  265;  MTI 
Radar  Simulation  receives  the  details 
of  a  radar  mission  from  the  radar 
subsystem  as  PSP  Parameter 
Messages. 

38. 

Prepare  the  system  for  the  next  procedure  or 
close  down  VSTARS  at  the  discretion  of  the  test 
conductor. 

VSTARS  is  either  made  ready  for 
the  next  V&V  procedure,  or  the 
system  is  shutdown. 
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4.2  ARIES  SAR  Verification  -  Demonstrate  that  VSTARS  displays  live  (noise  in  laboratory) 
SARs  in  live  AOIs,  and  virtual  SARs  in  mixed  and  virtual  areas  using  standard  Joint  STARS 
_ SAR  message  format. _ _ _ _ 


Step  # 

Action 

Event 

Pass/Fail 

1. 

In  ARIES  >  Verify  that  SAR  Simulation  is  still 
running.  If  not  follow  procedures  in  Appendix  A. 

2. 

In  DECterm  >  Type  rtmission  jadsOl. 

Rtmission  window  appears  showing 
logon  prompt. 

3. 

In  rtmission  >  Logon  to  MISSION2 

Prompt  for  password  and  perm 
number  displayed.  Logon  to  mission 

2  will  allow  access  to  the  RDP 
Message  Monitor. 

ft;';  -  . 

4. 

Go  to  the  options  feature  and  select  Restore 

Named  Options  in  the  pull  down  menu.  Select 

DECSTerminaLMSGMON.dat 

Displays  files  selection  options  for 
saved  window  names. 

p;  ’  " 

5. 

In  MSGMON  >  Type  jsmenu  16 

Invokes  the  Joint  STARS  Tools 

Menu. 

f.T  s 1  •* ■ '  ' 

6. 

In  MSGMON  >  Type  2 

Sets  up  the  Message  Monitor  Tool. 

l.  ■■ 

7. 

In  MSGMON  >  Type  3 

Brings  up  the  Message  Monitor  Tool 

§0:  ■  - 

8. 

In  MSGMON  >  Use  the  arrow  keys  to  select  Reset 
Collection  Process  type  4  and  press  return. 

This  will  clear  old  messages  from  the 
old  Message  Monitor  to  ensure  no 
other  SAR  message  traffic  is  present. 

Wf :  .  :.r- 

9. 

In  MSGMON  >  Use  the  arrow  keys  to  select 

Display  Msg  Summary  and  press  return. 

Summary  of  message  traffic  on 
VSTARS  is  displayed. 

S;  ..  *  .■  - 

10. 

Request  and  approve  a  SAR  in  a  virtual  area  at 
these  coordinates  290616N0465341E  and  give  it  a 
label  of  “virtual”.  Write  in  notes  section  below 
time  from  SAR  approval  to  display.  (This  is 
found  in  the  ARIES  window  next  to  elapsed  time) 

Write  in  RSR# 

SAR  request  is  sent  to  the  RSR  Que 
for  approval.  When  approved,  a 
virtual  SAR  displayed  on  the  GD. 

Pass  O 

Fail  □ 
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11. 

Request  and  approve  a  SAR  in  a  live  area  at  these 
coordinates  290247N0472414E.  Write  in  notes 
section  below  time  from  SAR  approval  to  display. 

Write  in  RSR# 

SAR  request  is  sent  to  the  RSR  Que 
for  approval.  When  approved,  a 
“live”  SAR  is  displayed  on  the  GD. 

Pass  O 

FaO  □ 

12. 

Request  and  approve  a  SAR  in  mixed  area  at  these 
coordinates  292317N0470011E.  Write  in  notes 
section  below  time  from  SAR  approval  to  display. 

Write  in  RSR# 

SAR  request  is  sent  to  the  RSR  Que 
for  approval.  When  approved,  a 
virtual  SAR  is  displayed  on  the  GD. 

p  p 

& 

□  □ 

13. 

In  the  Msg  Summary  window,  monitor  the  Msg 
Summary  Window  for  the  display  of  the 
SAR_Parameters_MSG_XD  and  the 
SAR_REPORT_RD  messages. 

These  messages  indicate  that  the 

Radar  has  received  a  SAR  request  in 
the  correct  SAR  message  format. 

14. 

In  the  Msg  Summary  window  press  return  to 
display  the  MSG  MON  window. 

The  main  Message  Monitor  window 
is  displayed. 

15. 

In  MSGMON  >  Use  the  arrow  keys  to  highlight 
Select  Display  of  Message  and  then  return. 

Choose  page  1  at  the  prompt. 

A  list  of  messages  processed  by 
VSTARS  is  displayed  and  available 
for  selection. 

16. 

In  MSGMON  >  Use  the  arrow  key  to  highlight  the 
SAR_REPORT_RD  and  then  return.  Choose 
page  1  at  the  prompt. 

Page  one  of  the  SAR_REPORT_RD 
is  displayed.  Watch  the  label  fields. 
Names  cycle  through  quickly. 

17. 

In  MSGMON  >  Look  in  the  source  field  for  a 
value  of  271  and  a  destination  of  391  to  show  that 
SARs  use  the  same  message  format  whether  they 
are  live,  virtual,  or  mixed. 

The  source  ID  of  271  indicates  the 
source  as  PK4SAR  and  the 
destination  of  391  indicates  the 
destination  as  PJSARS. 

Pass  O 

FaU  □ 

18. 

Request  and  approve  a  SAR  at  the  closest  distance 
from  the  E-8C  but  still  within  the  field  of  view  of 
the  radar. 

The  SAR  is  generated  and  displayed 
on  the  GD. 

Pass  Ul 

FaU  □ 

19. 

Request  and  approve  a  SAR  at  the  farthest 
distance  from  the  E-8C  but  still  within  the  field  of 
view  of  the  radar. 

The  SAR  is  generated  and  displayed 
on  the  GD. 

Pass  O 

Fan  Q 

20. 

Request  and  approve  a  SAR  at  the  forward  most 
limit  of  the  E-8C  but  still  within  the  field  of  view 
of  the  radar. 

The  SAR  is  generated  and  displayed 
on  the  GD. 

Pass  d 

FaU  □ 
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Pass/Fail 

21. 

Request  and  approve  a  SAR  at  the  aft  limit  of  the 
E-8C  but  still  within  the  field  of  view  of  the  radar. 

The  SAR  is  generated  and  displayed 
on  the  GD. 

Pass  1  1 

Fail  O 

Notes: 

Virtual  SAR  processing  time: 

Live  SAR  processing  time: 

Mixed  SAR  processing  time: 

The  following  steps  verify  the  FTI  (Fixed  Target  Indicator)  functionality  while  running  VSTARS. 

20. 

In  PJJMON  >  Select  the  MTI  parameters 
window  and  type  the  number  10  to  select  the 
minimum  detectable  speed.  Then  type  0.0  to  set 
speed  to  zero. 

Allows  the  operator  to  see  fixed 
targets  as  well  as  moving. 

"  - 

21. 

Ensure  the  12  target  scenario  is  still  running.  If  it 
has  stopped,  refer  to  Appendix  A. 

■  if/'  .■  ‘  -  . 

22. 

Use  the  right  mouse  to  access  the  pull-down 
menu  and  select  the  History  option. 

The  History  Playback  Window  is 
displayed. 

-  -  U 

23. 

In  the  History  Playback  Window  >  Select  the 
integrate  check  box  and  set  the  beginning  of 
playback  time  approximately  1  min  prior  to 
current  system  time.  Press  Return. 

MTI  will  replay  in  the  integration 
mode.  This  will  allow  the  operator  to 
distinguish  more  easily  between  the 
moving  and  the  fixed  targets. 

24. 

Look  at  the  GD  and  identify  a  target  that  is  not 
moving .  Scale  down  over  the  target  using  an 
expansion  of  8. 

Allows  for  a  better  view  of  the  target. 

25. 

On  the  push-button  menu,  select  PRI FNCT  and 
then  PROC  RSR.  From  PROC  RSR,  select 

RSR. 

Gives  access  to  the  RSR  push-button 
menu. 
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Pass/Fail 

26. 

On  the  RSR  menu,  click  on  FTI. 

The  FTI  window  is  displayed  to 
allow  the  operator  to  build  a  FTI. 

27. 

Highlight  the  POS  field  in  the  TD,  then  move  the 
cursor  over  the  fixed  target.  Use  the  middle  mouse 
button  to  fill  in  the  target’s  coordinates.  Press 
return.  Approve  the  RSR  in  the  RSR  QUE. 

An  FTI/SAR  is  “shot”  over  the  target 
area. 

28. 

An  FTI  appears  as  a  red  spot  over  the  location  of 
the  fixed  target. 

Pass  O 

Fail  □ 
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4.3  VSTARS  Operator  Interference  Verification  -  In  all  modes  of  operation,  VSTARS 
will  permit  all  the  installed  operator  workstation  software  to  function  without  the  occurrence  of 
abnormal  fault  messages  caused  by  VSTARS.abnormal  fault  messages  caused  by  VSTARS 

occurring. 


Step  # 

Action 

Event 

Pass/Fail 

1. 

Continue  to  run  VSTARS  with  SGI  file  active. 

SGI  scenario  and  VSTARS  run. 

Z"  ,  ... 

The  following  steps  verify  the  Route  functionality  while  running  VSTARS. 

2. 

Access  the  RTE  TD  from  the  process  track  push¬ 
button  menu. 

A  blank  Route  TD  is  displayed. 

V  •• 

3. 

Select  the  ADD  radio  button  and  then  the 

CARTO  option. 

The  system  highlights  the  PT  POS 
data  field  and  entered  points  are 
correlated  to  road  features. 

V,'. 

4. 

Select  points  along  a  primary  road  to  form  a 
cartographic  route  and  select  ENTER. 

A  white  line  appears  on  the  GD 
showing  location  of  new  route. 

i  -  - 

5. 

Select  the  ADD  radio  button  and  then  the  ARB 
option. 

The  system  highlights  the  PT  POS 
data  field  and  entered  points  are  not 
tied  to  cartographic  data. 

6. 

Select  points  along  a  primary  road  to  form  an 
arbitrary  route  and  select  ENTER. 

A  white  line  appears  on  the  GD 
showing  location  of  new  route. 

7. 

Open  the  ROUTE  LIST  TD  and  select  the 
arbitrary  route  for  modification. 

The  route  TD  for  the  selected  route  is 
displayed. 

•  ■  . ; 

8. 

Select  the  ADD  radio  button  and  then  the  ARB 
option. 

The  system  highlights  the  PT  POS 
data  field  and  entered  points  are  not 
tied  to  cartographic  data. 

9. 

Select  additional  arbitrary  points  to  modify  the 
route  and  press  ENTER. 

The  route  is  modified  with  new 
points  added. 

10. 

In  the  ROUTE  LIST  TD  select  the  cartographic 
route  for  deletion . 

The  cartographic  route  is  deleted. 
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Pass/Fail 

Route  functionality  is  available  while  running  VSTARS. 

Pass  Q 

Fail  □ 

Notes: 

The  following  steps  verify  the  Tracking  functionality  while  running  VSTARS. 

ii. 

Select  the  ETRK  option  on  the  PROC  TRK  push¬ 
button  menu. 

A  black  E-Track  TD  is  displayed. 

12. 

Initiate  an  E-Track  by  selecting  the  RDR 
DERIVED  radio  button,  in  the  RTE#  field  input 
the  number  of  the  previous  arbitrary  route,  and 
select  the  SEG  radio  button  to  use  the  segment 
method  to  determine  target  centroid  position. 

Press  ENTER. 

An  E-Track  is  initiated  using  the 
radar  to  determine  radial  velocity.  It 
is  constrained  to  the  route  previously . 
created,  and  it’s  centroid  position  is 
selected  via  the  segment  option. 

E-Track  functionality  is  available  while  running  VSTARS. 

Pass  O 

Fan  □ 

13. 

If  an  AC  area  is  not  created  over  targets,  initiate 
one. 

AC  is  displayed  on  the  GD  over  SGI 
targets. 

,.(‘s 

14. 

In  the  AC,  initiate  an  A-Track  by  selecting  the 
SPEC  SPD  CRS  radio  button,  do  not  select  a 
route  number,  and  use  the  CNTR  radio  button  to 
use  the  center  method  to  determine  target  centroid 
position.  Press  ENTER. 

An  A-Track  is  initiated  using 
operator  specified  speed  and  course. 

It  is  unconstrained  and  it’s  centroid 
position  is  selected  via  the  center 
option. 

fy  "  \  ' 

15. 

In  the  AC,  initiate  a  second  A-Track  by  selecting 
the  DP  1  and  DP  2  radio  buttons,  do  not  select  a 
route  number,  and  use  the  BOX  radio  button  to 
use  the  box  method  to  determine  target  centroid 
position.  Press  ENTER. 

An  A-Track  is  initiated  using 
differential  position.  It  is 
unconstrained  and  it’s  centroid 
position  is  selected  via  the  box 
option. 

A  42 
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Step  # 

Action 

Event 

16. 

Select  the  AUTO  REPOS  push-button  from  the 
PROC  TRK  push-button  menu. 

The  Automatic  Reposition  TD  is 
displayed. 

17. 

Highlight  the  AC  containing  the  A-Track ,  and 
then  input  the  A-Track  #  in  the  TRK#  field. 

Select  die  ENBL  check  button. 

The  AC  is  associated  to  the  selected 
A-Track  for  auto  repositioning. 

18. 

Monitor  the  Auto  Reposition  area  to  ensure  it 
repositions  as  the  A-Track  approaches  its  border. 

The  AC  area  auto  repositions  as  the 
assigned  A-Track  goes  outside  it’s 
boundary. 

A-Track  functionality  is  available  while  running  VSTARS. 

The  following  steps  verify  the  History  Playback  functionality  while  running  VSTARS. 

19. 

In  Display  Options ,  select  history  playback. 

History  Playback  window  is 
displayed. 

20. 

Select  integrate,  frame,  and  begin  10  min  prior  to 
current  system  time.  Select  Start. 

History  is  played  back  in 
continuously,  forming  a  “fuzzy 
caterpillar” 

21. 

Pause  history  and  select  Sliding  Window  in 
addition  to  integrate.  Put  window  size  at  10  and 
window  advance  to  10.  Select  Start. 

History  is  played  back  in  sliding 
window  and  integrate  mode.. 

Pass/Fail 


22.  Pause  history  and  deselect  both  integrate  and 
sliding  window.  Select  Start. 


History  plays  back  in  non-integration 
mode. 


History  Plalyback  functionality  is  available  while  running  VSTARS. 


Notes: 


The  following  steps  verify  the  Order  of  Battle  functionality  while  running  VSTARS. 
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Step  # 

Action 

Event 

Pass/Fail 

23. 

Select  OB  POINT  from  the  PROC  OB  push¬ 
button  menu. 

A  blank  Order  of  Battle  Point  TD  is 
displayed. 

24. 

Select  the  position  of  the  point  and  choose  the 
FRND  and  TROOP  radio  buttons.  Press 

ENTER. 

A  friendly  troop  OB  Point  is 
displayed. 

Pass  0 

Fail  □ 

25. 

Access  the  OB  POINT  SEL  TD  from  the  PROC 
OB  push-button  menu. 

The  Order  of  Battle  Selection  TD 
appears. 

Uiv  f 

26. 

Choose  the  FRND  check  button  and  the  ALL 
categories. 

The  Order  of  Battle  Point  List  TD  is 
accessed. 

27. 

Highlight  the  OB  point  just  created  and  the 
modify  option. 

The  OB  TD  for  the  friendly  troop  is 
displayed. 

28. 

Change  the  TROOP  selection  to  TRAIN.  Press 
ENTER. 

The  troop  symbol  becomes  a  train 
symbol  on  the  GD. 

Pass  O 

Fail  □ 

29. 

Open  the  OB  LINE  TD  from  the  PROC  OB 
push-button  menu. 

A  blank  Order  of  Battle  line  TD  is 
shown. 

30. 

Initiate  an  OB  Line  using  the  FLOT  option. 

Press  ENTER. 

A  FLOT  is  displayed  on  the  GD. 

Pass  LI 

Fail  □ 

31. 

Open  the  OB  LINE  LIST  using  the  PROC  OB 
push-button  menu,  and  select  FLOT  for 
modification . 

The  OB  Line  TD  for  the  selected  line 
is  opened. 

32. 

Delete  points  3  to  4  from  the  FLOT.  Press 
ENTER. 

Points  3-4  are  deleted. 

Pass  O 

Fail  □ 

33. 

Open  the  OB  AREA  TD  from  the  PROC  OB 
push-button  menu. 

A  blank  Order  of  Battle  Area  TD  is 
shown. 

34. 

Initiate  an  OB  Area  using  the  AOR  option. 

An  AOR  is  displayed  on  the  GD. 

P  P 

□  □ 
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Step  # 

Action 

Event 

Pass/Fail 

35. 

Open  the  OB  AREA  LIST  using  the  PROC  OB 
push-button  menu,  and  select  AOR  for 
modification. 

The  OB  Area  TD  for  the  selected 
area  is  opened. 

l;  :  • 

36. 

Insert  a  point  into  the  AOR.  Press  ENTER. 

The  modification  to  the  AOR  is 
shown  on  the  GD. 

Pass  f] 

FaU  □ 

Order  of  Battle  functionality  is  available  while  running  VSTARS. 

Pass  □ 

FaU  n 

Notes: 

The  following  steps  verify  the  Engagement  Point  functionality  while  running  VSTARS. 

37. 

Select  the  EP  TD  from  the  PROC  TRK  push¬ 
button  menu. 

A  blank  Engagement  Point  TD  is 
displayed. 

38. 

Choose  the  BASE  radio  button  and  input  the 
position  along  an  established  route.  Press 

ENTER. 

A  white,  base  engagement  point  is 
displayed  on  the  GD. 

Pass  Q 

FaU  □ 

39. 

Close  the  EP  TD. 

The  EP  TD  is  no  longer  displayed. 

40. 

Select  the  EP  TD  from  the  PROC  TRK  push¬ 
button  menu. 

A  blank  Engagement  Point  TD  is 
displayed. 

41. 

Initiate  a  constrained  E-track  15  km  in  front  of  the 
EP. 

An  E-Track  is  initiated  to  associate 
with  the  EP. 

42. 

Choose  the  ASSOC  radio  button.  Select  the  base 
EP  from  the  GD  and  input  in  the  BASE  EP  REF 
#  field.  Select  a  track  on  the  GD  and  input  in  the 
TRK#  field.  Press  ENTER. 

A  red,  associated  EP  is  shown  on  the 
GD,  and  Time  of  Arrival  info  is 
displayed  in  the  TOA  data  field. 

Pass  f] 

FaU  □ 
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Step  # 

Action 

Event 

Pass/Fail 

Engagement  Point  functionality  is  available  while  running  VSTARS. 

Pass  O 

Fail  □ 

Notes: 

The  following  steps  verify  the  Radar  Screening  functionality  while  running  VSTARS. 

43. 

Ensure  SGI  scenario  is  still  running.  If  not  restart 
it. 

■  ■■ 

44. 

Reinitiate  A-Track  on  data. 

Track  is  repositioned  on  radar  data. 

45. 

Access  the  RDR  SCRN  TD  from  the  PROC 

RSR  push-button  menu. 

The  Radar  Screening  TD  is  shown  on 
the  GD. 

46. 

Select  the  FXD  GND  PT  radio  button.  Then 
enter  the  position  of  a  ground  point  in  the  POS 
field.  Select  the  INACT  FLT  PLN  and  insert 
flight  plan  number.  Window  the  position  for  the 
starting  location  on  the  flight  plan  in  POS  1. 

Leave  POS  2  blank.  Press  ENTER. 

The  system  colors  the  flight  path  on 
the  GD  in  Vi  km  segments,  magenta 
for  visible,  cyan  for  screened. 

Pass  Q 

Fail  □ 

47. 

Select  the  RTE  SEG  radio  button.  Next,  input  a 
route  #  in  the  RTE  REF  #  field.  Window  the 
starting  point  for  the  route  request  in  the  POS  1 
field.  Choose  the  LGTH  radio  button  and  enter  40 
km.  Select  the  INACT  FLT  PLN  and  insert 
flight  plan  number.  Press  ENTER. 

The  system  colors  the  specified  route. 
If  the  route  segment  is  visible  from 
95%  of  the  flight  segment,  the  route 
segment  is  magenta,  if  it  is  between 
the  upper  and  lower  threshold  it  is 
amber.  If  it  is  below  the  lower 
threshold  it  is  cyan. 

Pass  O 

FaU  □ 

The  following  steps  verify  the  User  Defined  Activity  functionality  while  running  VSTARS. 

48. 

Access  the  User  Defined  Activity  (UDA) 
Indicator  TD  from  PROC  RSR  push-button 
menu. 

The  User  Defined  Activity  Indicator 
TD  is  displayed, 

j| 
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Step# 

Action 

49. 

Use  the  position  field  to  create  a  default  (4  km  x  4 
km)  UDA.  Select  coordinates  that  are  5  km  from 
in  front  of  a  targets  route  of  travel.  Change  the 

threshold  number  to  5.  Press  ENTER. 

A  4  km  x  4  km  User  Defined  Activity 
Indicator  Area  is  defined  10  km  in 
front  of  targets.  When  5  or  more 
targets  enter  the  UDA,  an  alert 
“UDA  threshold  exceeded”  appears 
and  the  UDA  border  thickens. 

Pass  LJ 

Fail  □ 

Notes: 

The  following  steps  verify  Timeline  Impact  functionality  while  running  VSTARS. 

50. 

Use  the  PROC  RSR  push-button  menu  to  access 
the  Timeline  Impact  (TL  IMPACT)  TD. 

The  Timeline  Impact  TD  is 
displayed. 

.’V- 

51. 

Select  the  FP  radio  button  and  input  the  inactive 
flight  plan  number  in  use.  Input  the  waypoint 
number,  and  enter  the  projected  time  the  AC  will 
be  at  that  waypoint.  Input  a  start  time  that  is  2 
minutes  later  than  the  waypoint  time.  Select 
duration  of  60  and  select  all  RSRs  for  projection. 
Press  ENTER. 

A  Timeline  Impact  TD  is  displayed 
for  the  inactive  flight  path  for  all 

RSRs  for  a  period  of  60  minutes. 

Pass  U| 

Fail  □ 

The  following  steps  verify  the  Update  Radar  Status  functionality  while  running  VSTARS. 

52. 

Open  RSR  QUE  TD,  the  Approved  List  TD,  and 
the  Pending  RSR  List  TDs. 

The  RSR  QUE  TD,  the  Approved 

List  TD,  and  the  Pending  RSR  List 
TDs  are  opened. 

53. 

Select  the  Update  Radar  Status  (UPDATE  RDR 
STATUS)  push-button  on  the  RDR  MGT  Push- 
Button  Menu. 

The  System  does  an  immediate 
update  of  the  RSR  QUE  TD,  the 
Approved  List  TD,  and  the  Pending 
RSR  List  TD. 

Pass  U| 

Fail  0 

The  following  steps  verify  the  Jammer  Sector  functionality  while  running  VSTARS. 

54. 

From  the  RDR  MGT  Push-Button  Menu,  select 
the  Jammer  Sector  (JMR  SCTR)  TD.  Input  a 
location  for  the  sector,  threshold  of  10,  and  a 
azimuth  width  of  15.  Press  ENTER. 

Jammer  Sector  is  displayed  on  the 

GD  as  a  wedge  centered  at  the 
indicated  location. 

Pass  Q 

Fail  □ 
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Step  # 

Action 

Event 

Pass/Fail 

The  following  steps  verify  the  Sector  and  Area  Blanking  functionality  while  running  VSTARS. 

55. 

From  the  RDR  MGT  Push-Button  Menu,  select 
the  Sector  Blanking  Service  Request  (SBSR)  area. 
Input  a  fixed  ground  point  location,  an  azimuth 
width  of  5,  and  a  duration  of  0.  Press  ENTER. 
(Ensure  that  SGI  scenario  is  running  and  that 
sector  is  located  over  targets.) 

The  Sector  Blanking  Request  is  sent 
to  the  RSR  QUE  for  approval. 

Pass  O 

Fail  □ 

56. 

Approve  the  SBSR  in  the  RSR  QUE . 

A  3°  sector  is  displayed  on  the  GD 
that  inhibits  all  radar  transmissions 
in  this  area.  Verify  that  targets  in  the 
sector  are  not  displayed. 

Pass  []] 

Fail  □ 

57. 

Delete  the  SBSR. 

The  blanked  sector  is  deleted  and 

MTI  appears  again  in  the  area. 

58. 

From  the  RDR  MGT  Push-Button  Menu,  select 
the  Area  Blanking  Service  Request  (ABSR)  area. 
Input  a  center  position  location  that  is  over 
virtual  targets  and  a  duration  of  0.  Press 

ENTER. 

The  Area  blanking  Service  request  is 
sent  to  the  RSR  QUE  for  approval. 

Pass  |D 

Fail  □ 

59. 

Approve  the  ABSR  in  the  RSR  QUE. 

A  lOx  10  ABSR  is  displayed  on  the 
GD.  Target  detections  in  this  area 
are  not  processed. 

Pass  n 

Fail  □ 

60. 

Delete  the  ABSR. 

The  blanked  sector  is  deleted  and 

MTI  appears  again  in  the  area. 

Notes: 

The  following  steps  verify  pull  down-menu  functionality. 

61. 

Access  modes  and  utilize  bearing  and  range  and 
free  form  functions. 

Bearing  and  range  and  free  form 
object  are  displayed  on  the  GD. 

Pass  [I] 

Fail  □ 
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Step  # 

Action 

Event 

62. 

Access  locate  entity  and  select  RSR  and  input 
number. 

A  large  arrow  on  the  GD  points  to 
selected  entity. 

Pass  Qj 

Fail  □ 

63. 

Select  the  point  option  and  send  a  point  to  the 
other  JADS  station. 

A  large  arrow  is  displayed  on  both 
JADSGDs. 

Pass  O 

Fail  □ 

64. 

Select  Cur  Coord  and  input  a  position  on  the  GD 
and  press  enter. 

The  Cur  Coord  TD  is  displayed  and 
the  position  is  converted  to  different 
coordinate  systems  in  the  TD. 

Pass  O 

Fail  □ 
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V&V  PROCEDURE  WITNESS  CERTIFICATION  DATE 


PROCEDURE  TITLE:  VSTARS  Operator  Interference  Verification 

This  acknowledges  that  the  V&V  procedure,  VSTARS  Operator  Interference  Verification  was 
performed  as  documented. 
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4.4  ANIU  and  GNIU  Verification  - 

4.4.1  Test  Case  #1:  Verify  that  the  GNIU  receives  and  processes  DIS  2.0.4 

Entity  State  Protocol  Data  Units  (ESPDU)  from  the  ETE  Test  DIS  network  at  a  rate  of  100 
ESPDUs/second.  Demonstrate  that  the  GNIU  can  process  ESPDUs  at  a  rate  greater  than  350 
ESPDU/second.  Verify  that  the  VSTARS  data  packet  is  than  192  bits. 


Step  # 

Action 

Event 

Pass/Fail 

The  folio1 

wing  steps  verify  GNIU  processing  rate  at  greater  than  350  ESPDUs  per  second. 

1. 

If  a  scenario  is  running,  select  CTRL-C  in  the 

SGI  window  to  stop  the  SGI  scenario. 

SGI  JADS  Logger  aborted  and 
stopped. 

2. 

In  DISNIU  >  Type  ZKKJRM  K 

DISNIU  and  DIS  monitor  are 
brought  down. 

3. 

In  DISNIU  >  Type  KKJR  PBK  JADS01 

Sets  up  playback  for  JADS01  and 
JADS02. 

4. 

In  DISNIU  >  Type  KKJR  SMAX  310 

Establishes  a  5  minute  processing 
time. 

'1  , 

5. 

In  DISNIU  >  Type  KKJR  PBKT0  360 

Offsets  the  start  of  the  scenario  to 

360  seconds. 

6. 

In  DISNIU  >  Type  KKJR  PBKX  250 

Set  a  playback  ratio  of  250  to  1 

7. 

In  DISNIU  >  Type  KKJR  CNFG  766 

JADS02  is  selected  to  be  the  external 
playback  unit  and  JADS01  the 
ground  and  air  units, 

!•'-  / 

8. 

In  DISNIU  >  Type  KKJR  LOG  2 

Log  mode  2  is  selected  to  record 
PDUs. 

In  DISNIU  >  Type  KKJR  PBK  R  TEST100 

Selects  a  playback  run  of  the  file  in 
DISPBK  and  also  establish  log  and 
recording  file  names. 

10. 

In  DISNIU  >  At  prompt,  X=abort/quit/exit, 
s=skip,  else=continue  Press  Enter 

Runs  the  scenario  playback. 

‘  '  VK-  • 
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Step  # 

Action 

Event 

Pass/Fail 

11. 

In  DISMON  >  “Up  arrow”  to  appropriate 
command  if  previously  activated,  if  not  follow 
procedures  in  Appendix  A. 

Allows  for  monitoring  of  DIS 
information. 

12. 

After  playback  is  complete,  in  DISNIU,  type 

KKJF 

Fetches  DIS  buffer  files. 

13. 

In  DISNIU  >  Type  ZKKJRM  K 

DISNIU  and  DIS  monitor  are 
brought  down. 

14. 

In  DISNIU  >  Type  KKJZ  JADS01  4  766  5  0 

Sets  DIS  up  for  an  analysis  run. 

15. 

In  DISNIU  >  Type  KKJR  PBKFNM 

DKB300:[DISPBK]D/tJ£_TEST100_INDY3. 

LOG 

Selects  the  file  for  analysis. 

i’V  d:-:.’,' . . '  -VV!!. 

16. 

In  DISNIU  >  Type  KKJR  PBKX  0 

Identifies  this  playback  as  an 
analysis. 

Sf*.  'v" 

17. 

In  DISNIU  >  Type  ZKKJR 

Runs  DIS  analysis 

18. 

Open  the  analysis  file  and  note  average  PDUs  per 
second. 

Will  show  number  of  PDUs  per 
second.. 

Pass  f] 

FaU  □ 

Notes: 
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Step  # 

Action 

Event 

Pass/Fail 

The  GNIU  receives  and  processes  DIS  2.0.4  ESPDUs  from  the  ETE  test  DIS  network  at  a 
rate  greater  than  350  ESPDUs  per  second. 

Pass  O 

Fail  □ 

The  following  confirms  the  total  bandwidth  requirements  between  GNIU  and  ANIU 

9. 

Multiply  the  maximum  ESPDU  rate  of  350 
ESPDUs/sec  times  the  ESPDU  data  packet  size 
of  192  bits 

350  x  .192  =  67.2  Kbits  per  second 

This  equation  confirms  that  the  total 
bandwidth  requirements  for  the  link 
between  the  ANIU  and  the  GNIU  are 
less  than  256  Kbits/sec  and  that  the 
bandwidth  is  no  less  than  19.2 
Kbits/sec. 

Pass  O 

Fail  □ 
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4.4.2  Test  Case  #2:  Verify  that  the  ANIU  provides  the  necessary  data  required 

by  the  GNIU,  and  that  the  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity  state 
of  the  E-8C  based  on  data  received  from  the  ANIU. 


The  following  steps  verify  that  the  GNIU  prepares  and  transmits  an  ESPDU  reflecting  the  entity 
state  of  the  E-8C  based  on  data  received  from  the  ANIU. 

1. 

In  DISNIU  window  >  Type  ZKKJRM  K  to  kill 
any  DIS  processes  currently  running. 

DIS  processes  are  terminated. 

2. 

In  the  SGI  window  >  Type  cd  /usr/local/bin  and 
press  ENTER. 

Points  to  the  directory  containing  the 
JADS  logging  tool. 

T...  ■  -  ' 

3. 

In  the  SGI  window  >  Type  ./jads logger  3000 

0  /disk2/logflles/date_e8pdu_indy3.1og  and 
press  ENTER. 

Prepares  the  SGI  to  record  files 
coining  across  the  DIS  network. 

4. 

In  DISNIU  window  >  Type 

kkjz  jadsOl  3  766  5  1 

The  DIS  network  interface  will  be 
set  up  to  run  on  jadsOl  in  the  run 
mode,  and  the  monitor  showing  the 
GNIU  data  for  entity  1. 

5. 

In  DISNIU  window  >  Type  KKJR  log  6  . 

Logs  the  E-8C  PDU. 

6. 

In  DISNIU  window  >  Type  ZKKJR. 

Runs  DISNIU 

||%  - 

7. 

In  DISMON  >  type 

@user$disk:  [util]  start_disniu_monitor. 

B.  Spalding  login  file  executes  to  set 
up  symbols  and  logicals.  Brings  up 
the  DISNIU  monitor. 

8. 

In  DISNIU  window  >  Type  ZKKJRM  P  2 

Turns  on  the  E-8C  PDU  generator  so 
it  will  run  regardless  of  external 

PDU  input. 

9. 

Note  time:  .  Keep  running 

for  5  minutes. 

E-8C  PDU  data  is  logged  to  the  SGI 
log. 

10. 

In  the  SGI  window  >  Monitor  window  to  verify 
that  the  PDU  count  is  increasing. 

Verifies  that  the  SGI  is  logging  the 
E-8C  PDU. 

•  •  •'  'ic, ,  ■ 

11. 

In  DISNIU  window  >  Type  ZKKJRM  K 

Kills -the  scenario  that  is  running. 
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12. 

On  the  SGI,  logon  as  root  and  sign  logbook. 

Provides  access  to  the  JADS  Logger 
Tool. 

p;  ' 

13. 

In  the  Deskl  menu  located  in  the  upper  left  comer 
of  the  SGI  display,  click  on  the  JADS  Toolbox 
and  slide  cursor  over  to  open. 

Opens  the  JADS  Toolbox. 

14. 

In  the  Test  Program  Selection  Box ,  highlight  ete 
and  click  OK. 

Selects  ete  as  the  test  program. 

15. 

In  the  Select  Logger  Type  window,  select  jads 
and  OK 

Displays  Test  Program  Selected  and 
Logger  Typed  Selected  as  ete  and 
jads  in  the  JADS  Analysis  Toolbox. 

16. 

Select  the  Dump  option  from  the  JADS  Analysis 
Toolbox  window  and  click  on  select  entity 
parameters. 

Opens  two  windows,  one  describing 
the  selections  functions,  and  the 
other  that  allows  for  file  selection. 

-p.;  '■  .  x,: ; 

17. 

In  the  Select  JADS  Log  File  window,  go  to  the 
Filter  Box  and  clear  everything  after  the/  and  type 
in  disk2/*  after  the  / 

Shows  available  files  for  analysis  in 
the  disk2  directory. 

18. 

From  the  list  of  available  files  select  the  e8pdu 
file  with  today’s  date  and  select  OK. 

The  Entity  State  Data  Items  window 
is  displayed. 

:  \  'N;  .  '  "i”  *  .  ' 

19. 

Highlight  the  following  parameters  for  analysis: 

Log  time,  Entity  ID,  Lat/Long,  Velocity  x,  y,  z 
(m/s) 

An  information  window  is  displayed 
stating  “Logfile  processing 
complete” 

20. 

In  the  information  window,  click  on  OK. 

The  window  is  closed,  and  the 
analysis  file  has  been  created. 

21. 

Go  to  the  /usr/data/results/(date  of  log)  directory 
to  access  the  E-8  PDU  file. 

A  .jprm  file  with  today’s  date  and 
the  logfile  name  is  displayed. 

22. 

Double  click  on  the  e-8pdu  jprm  file  to  open  file. 

A  log  file  is  opened  displaying  E-8C 
PDU  information. 

23. 

In  >  Verily  the  presence  of  E-8C  PDU  data  in 
the  file. 

The  presence  of  ESPDUs  verifies 
that  the  GNIU  prepares  and 
transmits  an  ESPDU  reflecting 
the  entity  state  of  the  E-8C  based 
on  data  received  from  the  ANIU. 

Pass  [D 

Fail  □ 

. 
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4.4.3  Test  Case  #3:  Verify  that  the  GNIU  performs  a  coordinate  transformation 

upon  entities  selected  for  transmittal  to  the  ANIU  and  prepares  a  VSTARS  data  packet, 
containing  all  entity  data  required  by  the  RPSI,  for  transmittal  to  the  ANIU.  In  addition, 
verify  that  the  ANIU  stores  entity  data  received  in  an  ANIU  Target  Database,  and  conducts 
dead  reckoning  upon  moving  targets  at  a  minimum  rate  of  1/second. 


The  following  steps  confirm 

■ 

In  DISNIU  >  Type  KKJR  JADS01  3  966  5  0 

The  DIS  network  interface  will  be 
set  up  to  run  on  jadsOl  in  the  run 
mode,  with  the  SGI  providing 
external  input,  and  the  monitor 
showing  the  GNIU  data. 

2. 

In  DISNIU  >  Type  LOGFNM 
DKB300:[DISLOG]ECEF_TCS 

Selects  ECEF_TCS  as  the  default 
logfile. 

3. 

In  DISNIU  >  Type  KKJR  LOG  7 

Selects  logging  of  Earth  Center 

Earth  Fixed  (ECEF)  and  Topocentric 
coordinate  system  for  ESPDUs. 

4. 

In  DISNIU  >  Type  ZKKJR. 

Runs  DISNIU. 

5. 

In  DISMON  >  Type 

@user$disk:[util]start_disnhi_monitor. 

B.  Spalding  login  file  executes  to  set 
up  symbols  and  logicals.  Brings  up 
the  DISNIU  monitor. 

6. 

In  DISMON  >  Look  at  the  field  beside  log  to 
verify  that  log-mode  is  set  to  7. 

Logger  will  log  both  GNIU  and 

ANIU  data  to  show  ECEF  and  TCS 
data. 

7. 

In  SGI  >  at  grumman  1#  prompt,  type 

cd  /usr/local/bin 

Brings  up  JADS  Logger. 

8. 

In  SGI  >  Type  Is 

Directory  is  displayed. 

9. 

In  SGI  >  Type  Is  /disk2/v_v_logfi!es  depending 
on  file  location  for  specified  scenario. 

List  of  directories  under  either 
v_v_logfiles  are  displayed. 

10. 

In  SGI  >  Type 

jads_player*  3000  1  /disk2/ v_v_logfiles 
/050498_testl00_indy3.1og 

Selected  pre-recorded  file  is  played 
back  on  the  SGI  and  transmitted  to 
JADS.Opens  selected  JADS  Logger 
file. 
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11. 

Ensure  that  there  are  targets  displayed  on  the  GD, 
and  that  the  DISMON  is  updating.  Let  the 
scenario  play  for  15  minutes. 

The  file  is  playing  back 
appropriately. 

12. 

In  SGI  >  Press  Ctrl-C 

Stops  the  SGI  playback  of  the 
scenario. 

'  '  y  ;  V  ^ 

13. 

In  DISNIU  >  Type  ZKKJRM  K. 

Kills  DIS 

14. 

In  DISNIU  >  Type  KKJF 

Fetches  data  from  the  circular 
buffer. 

15. 

In  DECterm  >  Type  set  def  dkb300:  [dislog] 

Changes  the  default  directory  to  the 
location  of  the  newly  recorded  log 
files. 

16. 

In  DEC  term  >  Type  PRINT  AXTN_ 
ECEF_TCS 

Prints  the  external  NIU  log  to  the 
default  printer. 

17. 

In  DECterm  >  Type  PRINT  BGND_ 
ECEF_TCS 

Prints  the  ground  NIU  log  to  the 
default  printer. 

18. 

In  DECterm  >  Type  PRINT  CAIR_ 
ECEF_TCS 

Prints  the  air  NIU  log  to  the  default 
printer. 

A  58 


DOCUMENT  NO:  C99SR090 
APPENDIX  E 
DATE:  4  June  1998 


V&V  PROCEDURE  WITNESS  CERTIFICATION  DATE 

PROCEDURE  TITLE:  ANIU  and  GNIU  Verification 

This  acknowledges  that  the  V&V  procedure,  ANIU  and  GNIU  Verification  was  performed  as 
documented. 


V&V  Conductor  (SBMS-M) 
Date 


Date 


V&V  Witness  (Government) 
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Turing  Test  -  The  Turing  Test  will  be  performed  by  Northrop  Grumman  and  the  Joint  STARS 
Joint  Test  Force  with  JADS  ETE  V&V  team  oversight.  The  purpose  of  the  Turing  Test 
is  to  ensure  that  there  are  no  major  distinguishable  differences  to  Joint  STARS 
operators  between  VSTARS  and  the  actual  Joint  STARS  radar  picture.  The  following 
areas  will  be  validated: 

•  Operational  behavior  characteristics  of  the  virtual  targets  shall  not  differ  noticeably 
from  the  operational  characteristics  of  real  targets  and  have  minimal  impact  upon  the 
radar  timeline. 

•  Validate  that  ARIES  visually  matches  the  fidelity  for  Joint  STARS  SAR  images,  and 
that  ARIES  has  minimal  impact  upon  the  radar  timeline. 


Step# 

Action 

Event 

Pass/Fail 

1. 

VSTARS  will  be  started  in  accordance  with 
Appendix  A.  JADS  JTF  coordinator  will 
indicate  which  mission  center  to  choose. 

VSTARS  is  up  and  operational; 
mission  center  for  this  mission  is 
selected  and  distributed. 

' 

2. 

Joint  STARS  JTF  will  provide  Air  Force 
operators  and  they  will  take  their  assigned 
positions. 

Simulation  is  manned  with  Air  Force 
operators  in  both  the  OCTL  and 

JADS  Lab  area. 

3. 

Air  Force  operators  will  be  briefed  on  mission 
scenario. 

Operators  ready  to  start  simulated 
mission. 

4. 

JADS  JTF  will  initiate  the  appropriate  scenario. 

Mission  scenario  is  started. 

5. 

JADS  psychologist  will  interview  all  operators  to 
verity  VSTARS  has  no  major  distinguishable 
differences  with  Joint  STARS  on  the  E-8C. 

Via  interviews  with  the  Joint  STARS 
operators,  JADS  psychologist 
determines  that  the  characteristics  of 
virtual  targets  and  ARIES  SARs  do 
not  differ  noticeably  from  real 
targets  and  SARs; 

ARIES  has  minimal  impact  upon  the 
radar  timeline. 

Pass 

Fail 
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V&V  PROCEDURE  WITNESS  CERTIFICATION 


DATE 


PROCEDURE  TITLE:  Turing  Test 

This  acknowledges  that  the  V&V  procedure,  Turing  Test  was  performed  as  documented. 


V&V  Conductor  (SBMS-M)  Date 

V&V  Witness  (Government)  Date 
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5.  Procedures  for  performing  JADS  Shutdown 


Step# 

Action 

Event 

Pass/Fail 

■ 

In  the  Session  Window  under  Applications  > 

Select  Stop  JSTARS  On  this  OWS. 

This  brings  down  Joint  STARS  and 
DecMessage  Que. 

2. 

In  ARIES  >  Press  Ctrl-C 

SAR  SIM  aborted  and  stopped 

l!-;  • ,  •;  v  - 

3. 

In  SGI  >  Press  Ctrl-C 

SGI  JADS  logger  aborted  and  stopped. 
Use  this  option  to  interrupt  SGI  during 
file  playback. 

4. 

In  SGI  >  Press  Ctrl-] 

SGI  JADS  logger  exit 

5. 

In  SGI  >At  telnet  prompt ,  type  exit 

Telnet  exit 

!>;• 

6. 

In  DISNIU>  Type  zkkjrm  k 

Kills  DISMON 

7. 

In  DISNIU  >  Type  lo 

Log  off  the  DISNIU  window. 

8. 

In  DISMON  >  Type  Ctrl-C 

Interrupts  DISMON. 

9. 

In  DISMON  >  Type  lo 

Log  off  the  DISMON  window. 

10. 

In  NSE  >  Use  the  cursor  to  select  “exit”  and  press 
return. 

NSE/RDI  configuration  widow 
displayed. 

1'  V  .  •  • 
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Step  # 

Action 

Event 

Pass/Fail 

11. 

In  NSE  >  Use  the  cursor  to  again  select  “exit”  and 
press  return. 

Window  display  reverts  to  original 
NSE/RDI  version  3.5  window. 

f|p:  ; 

12. 

In  NSE  >  type  exit 

NSE  processes  shut  down. 

f:  ;  '  :  v'  •• 

H 

In  NSE  >  Type  lo 

NSE  window  logs  off. 

1 

Log  off  the  OWS. 

The  Start  Session  window  is  displayed. 
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Table  3  Requirements  Cross-Reference  Paragraphs  for  VSTARS  Phase  II  V  &  V 


JADS  JTF  TAP 
DrnnroFMFNT 

NG  ENGINEERING 
nF«mivr  pppopt _ 

5.3.1  a  ! 

3.2.2.  [23] 

5.3.1  b 

3.2.1.1.1  [6,7] 

5.3.1  c 

3.2.3  [42] 

5.3.1  d 

3.1.1  [3]? 

5.3.1  e 

3.2.2  [23]? 

5.3.2  a 

3.2.1.3.4  [20] 

5.3.2  b 

3.2.1.3.3  [17,18] 

5.3.2  c 

3.2.1.3.4  [19] 

5.3.2  d 

3.2.1.3.6  [22] 

5.3.3  c 

3.2.1.3  [12] 

5.3.3  d 

3.2.1.3.5  [21] 

5.3.3  e 

3.2.4.3  [46] 

5.3.4  b 

3.2.2.1.3  [26],  3.2.2.1.4  ! 

5.3.4  c 

3.2.2.1.5  [28] 

5.3.4  d 

3.2.2  [28]? 

5.3.4  e 

3.2.3  [42] 

5.3.4  f 

3.2.3  [42]? 

5.3.5  b 

3.2.4.2  [45] 

5.3.5  b 

3.2.2.2  [29] 

5.3.5  d 

3.2.  2  [24] 

5.3.6  b 

3.2.3  [421 

5.3.6  c 

3.2.3  [41] 
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1.  SCOPE 


1.1  Identification. 

This  software  test  plan  (STP)  applies  to  the  computer  software  configuration  item  (CSCI) 
portion  of  the  Ground  Data  Terminal  (GDT)  1553  Bus  Interface  Unit  (1553  BIU).  The 
development  of  the  GDT  1553  BIU  is  under  the  direction  of  the  Joint  Advanced  Development 
Simulation  (JADS)  Joint  Test  and  Evaluation  (JT&E)  End-to-End  Test  (ETE)  organization  at 
Kirtland  AFB  in  New  Mexico. 

1.2  System  overview. 

The  JADS  JT&E  organization  is  charged  with  developing  the  capability  to  test  and 
evaluate  the  Joint  STARS  system  performance  through  a  hardware-in-the-loop  simulation.  One 
element  of  this  simulation  is  the  interface  between  the  Common  Ground  Station  (CGS)  and  the  E- 
8C  aircraft.  This  interface  is  normally  an  RF  link.  The  link  is  to  be  simulated  by  sending  link  data 
over  a  dedicated  T1  line.  This  requires  the  development  of  interface  software  at  both  ends  of  the 
T1  line  to  make  the  data  look  like  it  had  traversed  the  Surveillance  Control  Data  Link  (SCDL) 
rather  than  a  WAN  based  digital  connection.  The  specific  software  under  test  here  is  the  interface 
software  for  the  CGS  end  of  the  T1  line. 

1.3  Document  overview. 

This  STP  describes  the  formal  qualification  test  plans  for  the  GDT  1553  BIU.  It  identifies 
the  software  test  environment  resources  required  for  formal  qualification  testing  (FQT)  and 
provides  schedules  for  FQT  activities.  In  addition,  it  identifies  the  individual  tests  that  shall  be 
performed  during  FQT. 

1.4  Relationship  to  other  plans. 

There  are  no  other  plans  related  to  this  particular  activity  at  the  current  contract  level. 

2.  REFERENCED  DOCUMENTS 

Document  Number  Document  Title  Document  Date 


JADS-ICD-002 


Interface  Control  Document  for 
the  Ground  Station  Module  T-l 
LAN  Interface  of  the  Radar 
Processor  and  Integrator  for  Joint 
STARS 


January  1997 


Interface  Control  Document 
(ICD)  for  Ground  Station  Module 
(GSM)  Target  Acquisition 
Subsystem  to  Ground  Data 
Terminal  (GDT)  Group  OZ- 
64/GRY  Containing  LRU’s 
Nomenclatured  (V)3/G _ 


3.  SOFTWARE  TEST  ENVIRONMENT 

3.1  Software  items. 

The  software  items  necessary  to  perform  the  FQT  activities  include: 

Sim  Solaris  operating  system, 

Sun  C++  compiler, 

EDT  1553  device  driver, 

GDT  1553  BIU  application  code, 

CGS  1553  test  drivers,  and 
ADT  802.3  test  drivers. 

3.2  Hardware  and  firmware  items. 

The  computer  hardware,  interfacing  equipment,  and  firmware  items  that  will  be  used  in  the 
software  test  environment  include: 

Sun  SPARC  5  computer  (the  application  host), 

Sun  computer  (the  802.3  interface  emulator). 

Sun  computer  (the  1 553  interface  emulator), 

Joint  STARS  Common  Ground  Station  (CGS), 

JADS  supplied  IDNX, 

JADS  supplied  KIV-7HS,  and 
JADS  supplied  CSU/DSU. 

The  test  environment  for  CSCI  testing  will  be  unclassified.  The  test  environment  for 
system  level  testing  may  include  classified  information.  Whether  or  not  the  system  level  test 
information  is  classified,  the  testing  will  include  encryption  /  decryption  equipment  as  part  of  the 
test  setup. 

3.3  Proprietary  nature  and  government  rights. 

There  are  no  proprietary  rights  on  the  developed  software,  hardware,  or  firmware. 

3.4  Installation,  testing,  and  control. 

The  GDT  1553  BIU  application  code  will  be  installed  on  the  Sun  SPARC  5  computer 
prior  to  test.  The  application  code  and  all  test  software  will  be  maintained  under  Configuration 
Management  Version  Control  (CMVC)  prior  to  and  during  the  tests. 


4.  FORMAL  QUALIFICATION  TEST  IDENTIFICATION 


4.1.1  General  test  requirements. 

The  formal  qualification  of  the  GDT  1553  BIU  CSCI  shall  involve  the  use  of  nominal 
input  values.  Testing  with  erroneous  input  values  will  not  be  included. 

4.1.2  Test  classes. 

The  formal  qualification  testing  of  the  GDT  1553  BIU  CSCI  shall  include  functional  tests 
and  timing  tests. 

4.1.3  Test  levels. 

The  formal  qualification  testing  of  the  GDT  1553  BIU  CSCI  shall  be  performed  at  two 

levels: 

a.  CSCI  level-to  evaluate  compliance  with  CSCI  requirements.  These  tests  include  test 

definitions  4. 1 .4. 1  through  4. 1 .4.9. 

b.  System  level— to  validate  that  the  SCDL  interface  performs  properly  in  the  absence  of 

the  real  GDT.  These  tests  will  be  similar  in  nature  to  the  tests  performed  for  CSCI 
testing,  but  they  will  generally  be  performed  with  real  1553  and  802.3  interfaces 
rather  than  the  interface  emulators  used  in  the  CSCI  testing.  These  tests  include  test 
definitions  4. 1 .4. 10  through  4. 1 .4. 14 

4.1.4  Test  definitions. 

4. 1.4.1  GDT  Initial  Status. 

a.  Test  objective:  Verify  that  the  initial  GDT  status  reports  indicate  that  the  uplink  and 

downlink  are  not  enabled  and  that  the  other  status  report  elements  are  correct  for 
this  condition. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  not  send  a  control 

message  that  enables  the  uplink  or  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  None. 

4. 1.4.2  GDT  Initial  Status  Message  Blocking. 

a.  Test  objective:  Verify  that  uplink  and  downlink  traffic  are  not  passed  through  the  GDT 

1553  BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  not  send  a  control 

message  that  enables  the  uplink  or  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Presence  or  absence  of  uplink  messages  at  the  802.3 

interface  or  downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  1553  interface  emulator  is  sending  uplink  messages 


and  the  802.3  emulator  is  sending  downlink  messages. 

4. 1.4.3  GDT  Initial  Status  Transition. 

a.  Test  objective:  Verify  that  the  GDT  status  reports  indicate  that  the  uplink  and 

downlink  are  enabled  after  receipt  of  the  uplink  and  downlink  enabling  control 
messages  from  the  1553  emulator. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  first  enable  the  downlink 

and  then  enable  the  uplink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  The  GDT  1553  BIU  must  start  this  test  in  the  Initial 

Status  Mode  of  paragraph  4. 1 .4. 1 . 

4. 1 .4.4  GDT  Uplink  Messages. 

a.  Test  objective:  Verify  that  uplink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Uplink  messages  at  the  802.3  interface. 

g.  Assumptions  and  constraints:  The  1553  emulator  is  providing  periodic  uplink 

messages. 

4. 1.4.5  GDT  Uplink  Message  Latency. 

a.  Test  objective:  Verify  that  uplink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU  with  a  latency  of  less  than  100  milliseconds. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Time  of  Uplink  message  appearance  at  the  1553  and 

802.3  interfaces. 

g.  Assumptions  and  constraints:  The  1553  emulator  is  providing  periodic  uplink 

messages. 

4. 1 .4.6  GDT  Downlink  Messages. 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 


c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  downlink 

messages. 

4. 1.4.7  GDT  Downlink  Message  Latency. 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU  with  a  latency  of  less  than  100  milliseconds. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Downlink  messages  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  downlink 

messages. 

4. 1 .4.8  GDT  Aircraft  Location  Messages. 

a.  Test  objective:  Verify  that  the  Aircraft  Location  Message  is  correctly  converted  and 

passed  through  the  GDT  1553  BIU  in  the  GDT  Status  Report. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports  at  the  1553  interface. 

g.  Assumptions  and  constraints:  The  802.3  emulator  is  providing  periodic  aircraft 

location  messages. 

4. 1.4.9  GDT  Traffic  Capacity. 

a.  Test  objective:  Verify  that  GDT  1553  BIU  traffic  capacity  is  sufficient  to  pass  28 

Downlink  messages  and  one  Uplink  message,  to  process  one  Aircraft  Location 
message,  to  provide  one  GDT  Status  message  and  two  Transmit  Vector  Words 
messages  during  a  100  millisecond  time  interval. 

b.  Special  requirements:  For  this  test,  the  1553  emulator  must  have  already  enabled  the 

uplink  and  downlink. 

c.  Test  level:  CSCI. 

d.  Test  type  or  class:  Timing. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Time  of  Uplink  message  appearance  at  the  1553  and 

802.3  interfaces;  time  of  Downlink  message  appearance  at  the  802.3  and  1553 
interfaces;  time  of  Aircraft  Location  messages  appearance  at  the  802.3  interface;  and 
time  of  GDT  Status  and  TVW  messages  appearance  at  the  1553  interfaces. 


g.  Assumptions  and  constraints:  All  required  messages  are  provided  to  the  GDT  1553 
BIU  CSCI  at  the  proper  rates. 

4.1.4.10  GDT  Initial  Status. 

a.  Test  objective:  Verify  that  the  initial  GDT  status  reports  indicate  that  the  uplink  and 

downlink  are  not  enabled  and  that  the  other  status  report  elements  are  correct  for 
this  condition. 

b.  Special  requirements:  For  this  test,  the  CGS  must  not  send  a  control  message  that 

enables  the  uplink  or  downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  None. 

4. 1 .4. 1 1  GDT  Initial  Status  Transition. 

a.  Test  objective:  Verify  that  the  GDT  status  reports  indicate  that  the  uplink  and 

downlink  are  enabled  after  receipt  of  the  uplink  and  downlink  enabling  control 
messages  from  the  1553  emulator. 

b.  Special  requirements:  For  this  test,  the  CGS  must  first  enable  the  downlink  and  then 

enable  the  uplink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  The  GDT  1553  BIU  must  start  this  test  in  the  Initial 

Status  Mode  of  paragraph  4. 1.4.7. 

4. 1 .4. 12  GDT  Uplink  Messages. 

a.  Test  objective:  Verify  that  uplink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 

downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Uplink  messages  at  the  E-8C  interface  at  Northrop  / 

Grumman. 

g.  Assumptions  and  constraints:  The  CGS  is  providing  periodic  uplink  messages. 

4.1.4.13  GDT  Downlink  Messages. 

a.  Test  objective:  Verify  that  downlink  traffic  is  correctly  passed  through  the  GDT  1553 

BIU. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 

downlink. 


c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  Downlink  messages  at  the  CGS. 

g.  Assumptions  and  constraints:  The  E-8C  is  providing  periodic  downlink  messages. 

4.1.4.14  GDT  Aircraft  Location  Messages. 

a.  Test  objective:  Verify  that  the  Aircraft  Location  Message  is  correctly  converted  and 

passed  through  the  GDT  1 553  BIU  in  the  GDT  Status  Report. 

b.  Special  requirements:  For  this  test,  the  CGS  must  have  already  enabled  the  uplink  and 

downlink. 

c.  Test  level:  System. 

d.  Test  type  or  class:  Functional. 

e.  Qualification  method:  Demonstration. 

f.  Type  of  data  to  be  recorded:  GDT  Status  Reports. 

g.  Assumptions  and  constraints:  The  E-8C  is  providing  periodic  aircraft  location 

messages. 

4. 1 .5  Test  schedule. 

The  testing  of  the  GDT  1553  BIU  CSCI  shall  be  accomplished  as  soon  as  practical  after 
this  STP  receives  JADS  ETE  approval  and  dry-run  testing  verifies  that  the  software  passes  the 
tests  in  paragraphs  4. 1 .4. 1  through  4. 1 .4.9  of  this  STP.  The  system  level  testing  of  the  GDT 
1553  BIU  CSCI  shall  be  accomplished  as  soon  as  practical  after  completion  of  the  CSCI  level 
testing.  The  system  level  tests  are  defined  in  paragraphs  4.1.4.10  through  4.1.4.14. 

5.  DATA  RECORDING,  REDUCTION,  AND  ANALYSIS 

The  data  reduction  and  analysis  required  during  and  following  the  tests  identified  in  this 
STP  will  be  comparison  of  GDT  Status  Reports,  Uplink  Messages,  and  Downlink  Messages  with 
their  respective  expected  values  and  evaluation  of  appropriate  timing  entries  for  message  transmit 
and  receipt.  No  data  retention  will  be  required  other  than  logbook  entries  and  printouts  generated 
during  the  tests. 

6.  NOTES 

None. 


JADS  BIU  Qualification  Test  Procedure 


Three  test  configurations  are  identified  herein  to  support  the  test  levels  and  definitions 
described  by  the  previously  submitted  Software  Test  Plan.  This  procedure  describes  each  test 
configuration,  tests  conducted  for  that  configuration,  and  a  brief  procedure  for  each  test.  All  test 
definitions  from  the  Software  Test  Plan  are  included  within  this  procedure;  however ,  they  will  be 
executed  in  accordance  with  the  test  configuration  order  presented  below. 

Test  Configuration  I 

Software  Emulation  of  CGS  running  on  JADS  BIU  workstation 
JADS  BIU  Software  running  on  JADS  BIU  workstation 
Software  emulation  of  T1  Link  running  on  “Kong”  workstation 

Triax  termination  on  Primary  1553  connector  which  links  the  CGS  emulation  software  to  the 
JADS  BIU  software  via  1553  bus. 

Ethernet  Link  between  JADS  BIU  and  “Kong”  network 

When  each  of  the  three  software  components  have  been  initiated,  the  CGS  Emulator  will  send 
control  messages  and  uplink  messages  ( rate  =  0.1  Hz)  to  the  BIU  over  the  1553  bus, 
automatically  triggering  the  GDT  status  transitions.  The  T1  link  emulator  software,  upon 
receiving  the  first  uplink  message  from  the  BIU  over  the  Ethernet  link,  will  respond  by  sending 
downlink  messages  ( rate  =  80  Hz)  and  aircraft  location  messages  (  rate  =  1  Hz).  When  the  JADS 
BIU  software  transitions  to  the  downlink  enabled  mode,  it  will  pass  the  messages  through  the 
1553  bus  where  they  will  be  detected  by  the  CGS  Emulator  software.  Results  of  the  tests  will  be 
verified  by  examination  of  log  files  generated  as  the  above  scenario  is  executed. 

Test  Configuration  I  Coverage 

a)  GDT  Initial  Status  (STP  Paragraph  4. 1.4.1) 

Verify  Control  Word  portion  of  initial  GDT  Status  Report  from  CGS  Emulator  Log  File 

b)  GDT  Initial  Status  Message  Blocking  (STP  Paragraph  4. 1 .4.2) 

Examine  JADS  BIU  Log  File  to  verify  that  Uplink  messages  are  counted  only  when  Uplink  is 
enabled,  and  that  Downlink  messages  are  counted  only  when  downlink  is  enabled. 


c)  GDT  Initial  Status  Transition  (STP  Paragraph  4. 1.4.3) 

Examine  JADS  BIU  Log  File  to  verify  that  Uplink  Enabled  and  Downlink  enabled  mode 
transitions  take  place. 

d)  GDT  Uplink  Messages  (STP  Paragraph  4. 1 .4.4) 

Examine  T1  Emulator  Log  File  to  verify  the  indication  of  test  uplink  messages  passed  through  the 
JADS  BIU  and  transmitted  via  Ethernet  to  the  “Kong”  workstation. 

e)  GDT  Uplink  Message  Latency  (STP  Paragraph  4. 1.4.5) 

Examine  JADS  BIU  Log  File  to  record  maximum  and  average  Uplink  latency  values  in 
milliseconds. 

f)  GDT  Downlink  Messages  (STP  Paragraph  4. 1.4.6) 

Examine  JADS  BIU  Log  File  to  record  maximum  and  average  Uplink  latency  values  in 
milliseconds. 

g)  GDT  Aircraft  Location  Messages  (STP  Paragraph  4. 1.4.7) 

Examine  CGS  Emulator  Log  Files  to  verify  the  indication  of  Aircraft  Location  data  updating  the 
appropriate  fields  of  the  GDT  Status  message. 


Test  Configuration  II 


CGS  Server  1553  connection  to  provide  downlink  data  request 

JADS  BIU  Software  running  on  JADS  BIU  workstation 

Software  emulation  of  T1  Link  running  on  “Kong”  workstation 

Cable  connection  between  Primary  1553  connector  which  links  the  CGS  server  to  the  JADS  BIU 
software  via  1553  bus. 

Ethernet  Link  between  JADS  BIU  and  “Kong”  network 

Requests  for  downlink  data  are  generated  periodically  (20  Hz)  by  the  CGS  Server.  The  T1  link 
software  emulation  generates  aircraft  location  &  downlink  messages  at  a  rate  which  is  comparable 
to  that  supported  by  the  actual  T1  link  maximum.  Uplink  messages  will  be  generated  from  the 
CGS  workstation  console,  and  when  the  first  message  is  passed  through  the  JADS  BIU  to  the  T1 
emulation  software,  downlink  and  aircraft  location  message  transmission  will  begin.  Results  of  the 


tests  will  be  verified  by  log  files  generated  on  the  JADS  BIU  workstation. 

Test  Configuration  II  Coverage 

a)  GDT  Downlink  Latency  (STP  Paragraph  4. 1 .4.7) 

Examine  JADS  BIU  Log  File  to  record  maximum  and  average  Downlink  latency  values  in 
milliseconds. 

b)  GDT  Traffic  Capacity  (STP  Paragraph  4. 1.4.9) 

Examine  JADS  BIU  Log  File  to  record  maximum  throughput  rate  in  messages  per  second. 

Test  Configuration  III 

CGS  Server  1553  connection  to  JADS  BIU  workstation 

E8  Aircraft  Simulator  Connection  to  JADS  BIU  workstation  (  Tl/  IDNX ) 

The  workstation  will  require  re-configuration  and  re-boot  to  incorporate  new  IP  address  and  port 
data  ,  which  are  necessary  to  support  its  operational  configuration. 

Test  Configuration  III  Coverage 

a)  GDT  Initial  Status  (STP  Paragraph  4.1.4.10) 

Capture  GDT  Status  report  at  CGS  Console  using  Bus  Monitor  Log  facility. 

b)  GDT  Initial  Status  Transition  (STP  Paragraph  4.1.4.11) 

Use  CGS  Manage  Links  controls  and  periodic  status  displays  on  JADS  BIU  console  to  verily  the 
status  transitions. 

c)  GDT  Aircraft  Location  Messages  (STP  Paragraph  4.1.4.14) 

Use  CGS  Workstation  Imagery  window  to  display  the  simulated  E  -  8C  flight  path. 

d)  GDT  Uplink  Messages  (STP  Paragraph  4.1.4.12) 

Generate  RSR  &  Freetext  messages  using  CGS  Workstation  and  confirm  receipt  at  Grumman 
facility. 

e)  GDT  Downlink  Messages  (STP  Paragraph  4.1.4.12) 


Use  CGS  Message  Alert  facility  to  display  Freetext  message  originated  from  the  simulated  E  -  8C 
;  use  imagery  window  to  display  MTI  &  SAR  imagery  patterns. 


Appendix  C  -  V&V  Techniques 

The  following  is  a  description  of  verification  and  validation  (V&V)  techniques  that  will  be  used 
during  the  conduct  of  the  End-to-End  Test  V&V.  This  listing  is  not  all  inclusive  and  where  a 
technique  is  used  that  is  not  included  herein,  a  description  of  that  technique  will  be  described 
within  the  V&V  task  plan  and/or  the  V&V  task  report.  These  techniques  are  taken  from  the  DoD 
Verification.  Validation  and  Accreditation  fVV&A)  Recommended  Practices  Guide,  November 
1996,  Office  of  the  Director  of  Defense  Research  and  Engineering  Defense  Modeling  and 
Simulation  Office. 

Inspections 

A  team  with  four  to  six  members  inspects  any  modeling  and  simulation  (M&S)  development 
phase  such  as  M&S  requirements  definition,  conceptual  model  design,  or  M&S  detailed  design. 
To  inspect  M&S  design,  for  example,  the  team  might  consist  of  a  moderator  who  manages  the 
inspection  team  and  provides  leadership;  a  reader  who  narrates  the  M&S  design  and  leads  the 
team  through  the  inspection  process;  a  recorder  who  produces  a  written  report  of  detected  faults; 
a  designer  who  represents  the  design  developer;  an  implementer  who  translates  the  M&S  design 
into  an  executable  form;  and  a  W&A  agent. 

An  inspection  goes  through  five  distinct  phases:  overview,  preparation,  inspection,  rework,  and 
follow-up  (Schach,  1996).  In  Phase  1,  the  designer  summarizes  the  M&S  design  to  be  inspected. 
Characteristics  such  as  problem  definition,  application  requirements,  and  the  specifics  of  software 
design  are  introduced  and  related  documentation  is  distributed  to  all  participants  to  study.  In 
Phase  2,  the  team  members  prepare  individually  for  the  inspection  by  examining  the  documents  in 
detail.  The  success  of  the  inspection  rests  heavily  on  the  conscientiousness  of  the  team  members 
in  their  preparation.  The  moderator  arranges  the  inspection  meeting  with  an  established  agenda 
and  chairs  it  in  Phase  3.  The  reader  narrates  the  M&S  design  documentation  and  leads  the  team 
through  the  inspection  process.  The  inspection  team  is  aided  during  the  fault-finding  process  by  a 
checklist  of  queries.  The  objective  is  to  find  and  document  the  faults,  not  to  correct  them.  The 
recorder  prepares  a  report  of  detected  faults  immediately  after  the  meeting.  In  Phase  4,  the 
designer  resolves  all  faults  and  problems  identified  in  the  report.  In  the  final  phase,  the  moderator 
ensures  that  all  faults  and  problems  have  been  resolved  satisfactorily.  All  changes  must  be 
examined  carefully  to  ensure  that  no  new  errors  have  been  introduced  as  a  result  of  a  fix. 

Turing  Test 

Turing  test  is  based  upon  the  expert  knowledge  of  people  about  the  system  of  interest.  The 
experts  are  presented  with  two  sets  of  output  data,  one  obtained  from  the  model  and  one  from  the 
system,  under  the  same  input  conditions.  Without  identifying  the  data  set,  the  experts  are  asked 
to  differentiate  between  the  two.  If  they  succeed,  they  are  asked  to  describe  the  differences. 
Their  responses  provide  valuable  feedback  for  correcting  model  representation.  If  they  cannot 
differentiate  between  the  two,  confidence  in  the  model’s  validity  is  increased  (Schruben,  1980; 
Turing,  1963;  Van  Horn,  1971). 


Cause-Effect  Graphing 


Cause-effect  graphing  addresses  the  question  of  what  causes  what  in  the  model  representation.  It 
first  identifies  causes  and  effects  in  the  system  being  modeled  and  then  examines  their 
representation  in  the  model  specification.  For  example,  in  a  simulation  of  a  traffic  intersection  the 
following  causes  and  effects  may  be  identified:  (a)  the  change  of  a  light  to  red  immediately  causes 
the  vehicles  in  the  traffic  lane  to  stop  (except  in  Albuquerque,  New  Mexico),  (b)  an  increase  in  the 
duration  of  a  green  light  causes  a  decrease  in  the  average  waiting  time  of  vehicles  in  the  traffic 
lane,  and  an  increase  in  the  arrival  rate  of  vehicles  causes  an  increase  in  the  average  number  of 
vehicles  at  the  intersection. 

As  many  causes  and  effects  as  possible  are  listed,  and  the  semantics  are  expressed  in  a  cause- 
effect  graph.  The  graph  is  annotated  to  describe  special  conditions  or  impossible  situations.  Once 
the  cause-effect  graph  has  been  constructed,  a  decision  table  is  created  by  tracing  back  through 
the  graph  to  determine  combinations  of  causes  that  result  in  each  effect.  The  decision  table  is 
then  converted  into  test  cases  with  which  the  model  is  tested  (Myers,  1979;  Pressman,  1996; 
Whitner  and  Balci,  1989). 

Acceptance  Testing 

Acceptance  testing  is  conducted  by  either  the  M&S  application  sponsor  and  the  sponsor’s  W&A 
agents  or  the  developer’s  quality  control  group  in  the  presence  of  the  sponsor’s  representatives. 
The  model  is  operationally  tested  with  the  actual  hardware  and  data  to  determine  whether  all 
requirements  specified  in  the  legal  contract  are  satisfied  (Perry,  1995;  Schach,  1996). 

Execution  Monitoring 

Execution  monitoring  reveals  errors  by  examining  low-level  information  about  activities  and 
events  that  take  place  during  model  execution.  It  requires  the  instrumentation  of  a  model  or 
simulation  to  gather  data  to  provide  activity-  or  event-oriented  information  about  the  model’s 
dynamic  behavior.  For  example,  a  model  of  air  travel  can  be  instrumented  to  monitor  the  arrivals 
and  departures  of  aircraft  within  a  particular  city,  and  the  results  can  be  compared  with  the  official 
airline  guide  to  judge  model  validity.  The  model  also  can  be  instrumented  to  provide  other  low- 
level  information  such  as  the  number  of  late  arrivals,  the  average  passenger  waiting  time  at  the 
airport,  and  the  average  flight  time  between  two  locations. 

Functional  Testing 

Functional  testing  (also  called  black-box  testing)  assesses  the  accuracy  of  model  input-output 
transformation.  It  is  applied  by  feeding  inputs  (test  data)  to  the  model  and  evaluating  the 
accuracy  of  the  corresponding  outputs. 

It  is  virtually  impossible  to  test  all  input-output  transformation  paths  for  a  reasonably  large  and 
complex  simulation  because  the  number  of  these  paths  could  be  in  the  millions.  Therefore,  the 


objective  of  functional  testing  is  to  increase  confidence  in  model  input-output  transformation 
accuracy  as  much  as  possible  rather  than  to  claim  absolute  correctness. 

The  generation  of  test  data  is  a  crucially  important  but  very  difficult  task.  The  law  of  large 
numbers  does  not  apply  here.  Successfully  testing  the  model  under  1,000  input  values  (test  data) 
does  not  imply  high  confidence  in  model  input-output  transformation  accuracy  just  because  of  the 
large  number.  Instead  the  number  1,000  should  be  compared  with  the  number  of  allowable  input 
values  to  determine  the  percentage  of  the  model  input  domain  that  is  covered  in  testing.  The 
more  the  model  input  domain  is  covered  in  testing,  the  more  confidence  is  gained  in  the  accuracy 
of  the  model  input-output  transformation  (Howden,  1980;  Myers,  1979). 

Data  Verification 

Data  verification  assesses  the  adequacy,  sufficiency,  and  usability  of  the  input  data  and  databases. 
Data  verification  will  evaluate  the  ability  of  shared  data  (e.g.,  terrain,  force  structure, 
environmental  data)  to  address  the  operational  requirements  and  produce  an  appropriate  synthetic 
environment;  compare  M&S  component  and  exercise  data  applications  to  ensure  a  high  degree  of 
consistency  in  the  data  exchanged;  assess  key  data  elements  for  appropriate  use  and  consistent 
valuation;  ensure  data  transfers  and  manipulations  do  not  violate  exercise  security  policies;  and 
review  the  suitability  of  special  data  requirements  resulting  from  the  testing  and  data  collection. 
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